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Programming Languages 


Computer scientists often need to learn new programming languages quickly. The best way to 
prepare is to understand the foundational principles that underlie even the most complicated industrial 
languages. 

This text for an undergraduate programming-languages course distills great languages and their 
design principles down to easy-to-learn “bridge” languages implemented by interpreters whose key 
parts are explained in the text. The book goes deep into the roots of both functional and object-oriented 
programming, and it shows how types and modules, including generics/polymorphism, contribute to 
effective programming. 

The book is not just about programming languages; it is also about programming. Through 
concepts, examples, and more than 300 practice exercises that exploit the interpreters, students learn 
not only what programming-language features are common but also how to do things with them. 
Substantial implementation projects include Milner’s type inference, both copying and mark-and- 
sweep garbage collection, and arithmetic on arbitrary-precision integers. 


Norman Ramsey is Associate Professor of Computer Science at Tufts University. Since earning his 
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functional programming, programming language implementation, and technical writing at Purdue, 
the University of Virginia, and Harvard as well as Tufts. He has received Tufts’s Lerman-Neubauer 
Prize, awarded annually to one outstanding undergraduate teacher. He has also been a Hertz Fellow 
and an Alfred P. Sloan Research Fellow. His implementation credits include a code generator for the 
Standard ML of New Jersey compiler and another for the Glasgow Haskell Compiler. 
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Preface 


This textbook, suitable for an undergraduate or master’s-level course in program- 
ming languages, is about great language-design ideas, how to describe them pre- 
cisely, and how to use them effectively. The ideas revolve around functions, types, 
modules, and objects. They are described using formal semantics and type theory, 
and their use is illustrated through programming examples and exercises. 

The ideas, descriptive techniques, and examples are conveyed by means of 
bridge languages. A bridge language models a real programming language, but it is 
small enough to describe formally and to learn in a week or two, yet big enough 
to write interesting programs in. The bridge languages in this book model Algol, 
Scheme, ML, CLU, and Smalltalk, and they are related to many modern descen- 
dants, including C, C++, OCaml, Haskell, Java, JavaScript, Python, Ruby, and Rust. 

Each bridge language is supported by an interpreter, which runs all the exam- 
ples and supports programming exercises. The interpreters, which are presented 
in depth in an online Supplement, are carefully crafted and documented. They can 
be used not only for exercises but also to implement students’ own language-design 
ideas. 

The book develops these concepts: 


+ Abstract syntax and operational semantics 

* Definitional interpreters 

+ Algebraic laws and equational reasoning 

* Garbage collection 

* Symbolic computing and functional programming 
* Parametric polymorphism 

* Monomorphic and polymorphic type systems 

* Type inference 

+ Algebraic data types and pattern matching 

* Data abstraction using abstract types and modules 


* Data abstraction using objects and classes 


The concepts are supported by the bridge languages as shown in the Introduc- 
tion (Table 1.2, page 5), which also explains each bridge language in greater detail 
(pages 3 to 7). 

The book calls for skills in both programming and proof: 


» As prerequisites, learners should have the first-year, two-semester program- 
ming sequence, including data structures, plus discrete mathematics. 


* Toextend and modify the implementations in Chapters 1 to 4, alearner needs 
to be able to read and modify C code; the necessary skills have to be learned 
elsewhere. C is used because it is the simplest way to express programs that 
work extensively with pointers and memory, which is the topic of Chapter 4. 
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To extend and modify the implementations in Chapters 5 to 10, a learner 
needs to be able to read and modify Standard ML code; the necessary skills 
are developed in Chapters 2, 5, and 8. Standard ML is used because it is a 
simple, powerful language that is ideally suited to writing interpreters. 


* To prove the simpler theorems, a learner needs to be able to substitute equals 
for equals and to fill in templates of logical reasoning. To prove the more 
interesting theorems, a learner needs to be able to write a proof by induction. 


DESIGNING A COURSE TO USE THIS BOOK 


Some books capture a single course, and when using such a book, your only choice 
is to start at the beginning and go as far as you can. But in programming languages, 
instructors have many good choices, and a book shouldn’t make them all for you. 
This book is designed so you can choose what to teach and what to emphasize while 
retaining a coherent point of view: how programming languages can be used effec- 
tively in practice. If you’re relatively new to teaching programming languages and 
are not sure what to choose, you can’t go wrong with a course on functions, types, 
and objects (Chapters 1, 2, 6, 7, and 10). If you have more experience, consider the 
ideas below. 

Programming Languages: Build, Prove, and Compare gives you interesting, pow- 
erful programming languages that share acommon syntax, a common theoretical 
framework, and a common implementation framework. These frameworks sup- 
port programming practice in the bridge languages, implementation and extension 
of the bridge languages, and formal reasoning about the bridge languages. The de- 
sign of your course will depend on how you wish to balance these elements. 


* To unlock the full potential of the subject, combine programming practice 
with theoretical study and work on interpreters. If your students have only 
two semesters of programming experience and no functional programming, 
you can focus on the core foundations in Chapters 1 to 3: operational seman- 
tics, functional programming, and control operators. You can supplement 
that work with one of two foundational tracks: If your students are com- 
fortable with C and pointers, they can implement continuation primitives 
in wScheme-+, and they can implement garbage collectors. Or if they can 
make a transition from zScheme to Standard ML, with help from Chapter 8, 
they can implement type checkers and possibly type inference. 


If your students have an additional semester of programming experience or 
if they have already been exposed to functional programming, your course 
can advance into types, modules, and objects. When I teach a course like 
this, it begins with four homework assignments that span an introduction 
to the framework, operational semantics, recursive functions, and higher- 
order functions. After completing these assignments, my students learn 
Standard ML, in which they implement first a type checker, then type infer- 
ence. This schedule leaves a week for programming with modules and data 
abstraction, a couple of weeks for Smalltalk, and a bit of time for the lambda 
calculus. 


A colleague whose students are similarly experienced begins with Impcore 
and pScheme, transitions to Standard ML to work on type systems and 
type inference, then returns to the bridge languages to explore Smalltalk, 
LProlog, and garbage collection. 


If your students have seen interpreters and are comfortable with proof by 
induction, your course can move much more quickly through the founda- 


tional material, creating room for other topics. When I taught a course like 
this, it explored everything in my other class, then added garbage collection, 
denotational semantics, and logic programming. 


A second design strategy tilts your class toward programming practice, ei- 
ther de-emphasizing or eliminating theory. To introduce programming prac- 
tice in diverse languages, Build, Prove, and Compare occupies a sweet spot be- 
tween two extremes. One extreme “covers” NV languages in N weeks. This 
extreme is great for exposure, but not for depth—when students must work 
with real implementations of real languages, a week or even two may be 
enough to motivate them, but it’s not enough to build proficiency. 


The other extreme goes into full languages narrowly but deeply. Students 
typically use a couple of popular languages, and overheads are high: each 
language has its own implementation conventions, and students must man- 
age the gratuitous details and differences that popular languages make in- 
evitable. 


Build, Prove, and Compare offers both breadth and depth, without the over- 
head. If you want to focus on programming practice, you can aim for “four 
languages in ten weeks”: uScheme, {sML, Molecule, and Smalltalk. You can 
bring your students up to speed on the common syntactic, semantic, and im- 
plementation frameworks using Impcore, and that knowledge will support 
them through to the next four languages. If you have a couple of extra weeks, 
you can deepen your students’ experience by having them work with the in- 
terpreters. 


- A third design strategy tilts your class toward applied theory. Build, Prove, 
and Compare is not suitable for a class in pure theory—the bridge languages 
are too big, the reasoning is informal, and the classic results are miss- 
ing. But it is suitable for a course that is primarily about using formal 
notation to explain precisely what is going on in whole programming lan- 
guages, reinforced by experience implementing that notation. Your stu- 
dents can do metatheory with Impcore, Typed Impcore, Typed wScheme, 
and nano-ML; equational reasoning with Scheme; and type systems with 
Typed Impcore, Typed Scheme, nano-ML, wML, and Molecule. They can 
compare how universally quantified types are used in three different designs 
(Typed wScheme, nano-ML/}:ML, and Molecule). 


* What abouta course in interpreters? Ifyou are interested in definitional inter- 
preters, Build, Prove, and Compare presents many well-crafted examples. And 
the online Supplement presents a powerful infrastructure that your students 
can use to build more definitional interpreters (Appendices F to I). But apart 
from this infrastructure, the book does not discuss what a definitional in- 
terpreter is or how to design one. For a course on interpreters, you would 
probably want an additional book. 


All of these potential designs are well supported by the exercises (345 in total), 
which fall into three big categories. For insight into how to use programming lan- 
guages effectively, there are programming exercises that use the bridge languages. 
For insight into the workings of the languages themselves, as well as the formalism 
that describes them, there are programming exercises that extend or modify the 
interpreters. And for insight into formal description and proof, there are theory ex- 
ercises. Model solutions for some of the more challenging exercises are available 
to instructors. 


Designing a course 
to use this book 
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A few exercises are simple enough and easy enough that your students can work 
on them for 10 to 20 minutes in class. But most are intended as homework. 


* To introduce a new language like Impcore, Scheme, “ML, Molecule, or 
pSmalltalk, think about assigning from a half dozen to a full dozen program- 
ming exercises, most easy, some of medium difficulty. 


* To introduce proof technique, think about assigning around a half dozen 
proof problems, maybe one or two involving some form of induction (some 
metatheory, or perhaps an algebraic law involving lists). 


* To develop a deep understanding of a single topic, assign one exercise or a 
group of related exercises aimed at that topic. Such exercises are provided 
for continuations, garbage collection, type checking, type inference, search 
trees, and arbitrary-precision integers. 


CONTENTS AND SCOPE 


Because this book is organized by language, its scope is partly determined by what 
the bridge languages do and do not offer relative to the originals on which they are 
based. 


+ pScheme offers define, a lambda, and three “let” forms. Values include sym- 
bols, machine integers, Booleans, cons cells, and functions. There’s no nu- 
meric tower and there are no macros. 


* UML offers type inference, algebraic data types, and pattern matching. 
There are no modules, no exceptions, no mutable reference cells, and no 
value restriction. 


* Molecule offers a procedural, monomorphic core language with mutable al- 
gebraic types, coupled to a module language that resembles OCaml and Stan- 
dard ML. 


pSmalltalk offers a pure object-oriented language in which everything is an 
object; even classes are objects. Control flow is expressed via message pass- 
ing in a form of continuation-passing style. wSmalltalk provides a modest 
class hierarchy, which includes blocks, Booleans, collections, magnitudes, 
and three kinds of numbers. And Smalltalk includes just enough reflection 
to enable programmers to add new methods to existing classes. 


Each of the languages supports multiple topical themes; the major themes are 
programming, semantics, and types. 


* Idiomatic programming demonstrates effective use of proven features that are 
found in many languages. Such features include functions (wScheme, Chap- 
ter 2), algebraic data types (UML, Chapter 8), abstract data types and modules 
(Molecule, Chapter 9), and objects (wSmalltalk, Chapter 10). 


+ Big-step semantics expresses the meaning of programs in a way that is easily 
connected to interpreters, and which, with practice, becomes easy to read 
and write. Big-step semantics are given for Impcore, zScheme, nano-ML, 
LML, and pwSmalltalk (Chapters 1, 2, 7, 8, and 10). 


* Type systems guide the construction of correct programs, help document 
functions, and guarantee that language features like polymorphism and data 
abstraction are used safely. Type systems are given for Typed Impcore, 
Typed wScheme, nano-ML, /sML, and Molecule (Chapters 6 to 9). 


In addition the major themes and the concepts listed above, the book addresses, 
to varying degrees, these other concepts: 


* Subtype polymorphism, in Smalltalk (Chapter 10) 


* Light metatheory for both operational semantics and type systems (Chap- 
ters 1, 5, and 6) 


* Free variables, bound variables, variable capture, and substitution, in both 
terms and types (Chapters 2, 5, and 6) 


* Continuations for backtracking search, for small-step semantics, and for 
more general control flow (Chapters 2, 3, and 10) 


* The propositions-as-types principle, albeit briefly (Chapter 6 Afterword) 


A book is characterized not only by what it includes but also by what it omits. 
To start, this book omits the classic theory results such as type soundness and 
strong normalization; although learners can prove some simple theorems and look 
for interesting counterexamples, theory is used primarily to express and commu- 
nicate ideas, not to establish facts. The book also omits lambda calculus, because 
lambda calculus is not suitable for programming. 

The book omits concurrency and parallelism. These subjects are too difficult 
and too ramified to be handled well in a broad introductory book. 

And for reasons of space and time, the book omits three engaging program- 
ming models. One is the pure, lazy language, as exemplified by Haskell. An- 
other is the prototype-based object-oriented language, made popular by JavaScript, 
but brilliantly illustrated by Self. The third is logic programming, as exemplified 
by Prolog—although Prolog is explored at length in the Supplement (Appendix D). 
If you are interested in jsHaskell, Self, or jsProlog, please write to me. 


SOFTWARE AND OTHER SUPPLEMENTS 


The software described in the book is available from the book’s web site, which is 
build-prove-compare.net. The web site also provides a “playground” that allows 
you to experiment with the interpreters directly in your browser, without having to 
download anything. And it holds the book’s PDF Supplement, which includes ad- 
ditional material on multiprecision arithmetic, extensions to algebraic data types, 
logic programming, and longer programming examples. The Supplement also de- 
scribes all the code: both the reusable modules and the interpreter-specific mod- 
ules. 


Software and other 
supplements 
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Judgment forms, important functions, & concrete syntax 


Evaluation judgments 
Language Expression or related form Page Definition Page 
Impcore (e, &, d, p) al (vu, bes dg, p’) 30 (d, &; ¢) mr (E' ¢’) 37 
pScheme (e, p, 0) | (v, 0’) 144 (d, p,7) + (p', a") 151 
pScheme+ (e/v, p,o, S) > 215 (d, p,7) + (p', a") 222 
(e!/v', ,0', 8") 
TypedImpcore (asin Impcore) 30 37 
Typed wScheme (e, p,c) |) (v, 0’) 380 (as in Impcore) 151 
nano-ML (e, p) di v 405 (d,p) > p’ 405 
PML (e, p) I 491 (as in nano-ML) 405 
(p,v) > r (pattern match) 490 
Smalltalk 
definition (d,&,0,F) > (€',0', F’) 684 
expression finishes (e€, p, Csuper, F,€,0,F) | (v3 0", F’) 679 
expression returns (€, , Csuper, F,€,0,F) t (v, F’3 0’, F’) 679 
expressions return ([€1,...,€n], P, Csuper, L',€,0, F) t (vu, F’;3 0’, F’) 679 
expressions finish ([e1,...,€n], 0, Csuper, F, €,0, F) 4 ([ui,...,un};o’, F’) 679 
primitive (p, [v1,---,Un],€,0;F) Wp (uj; 0, F’) 679 
method dispatch mb c@imp 681 
Typing judgments 
Language Expression or related form Page Definition Page 
TypedImpeore T¢e,T¢,T,+ e:7 335 (d,Te,Te) > Fe,0%) 336 
Typed uScheme A,T be: 7 363 (d,T) 31’ 366 
nano-ML [+ e:7(mondeterministic) 413 (d,T) 31’ 416 
61 + e: 7 (with substitutions) 418 (d,T) 31’ 416 
C,Tt e: 7 (with constraints) 418 (d,T) 31’ 416 
UML (as in nano-ML) 418 (as in nano-ML) 416 
[,I’ + p: 7 (pattern) 496 
Molecule (14 judgment forms are shown in Chapter 9, Figure 9.14) 565 
Well-formedness judgments 
Language Form Judgment Page 
Typed Impcore Type T isa type 334 
Typed Scheme Kind Kis a kind 354 
Type ARTI 355 


Evaluation and type-checking functions 


Evaluation Type checking and elaboration 
Language Exp. Page Def. Page Exp. Page Def. Page 
Impcore eval 48 evaldef 53 
pScheme eval 155 evaldef 159 
puScheme+ eval 227  evaldef 159 
Scheme (inML) eval 309  evaldef 311 
Typed Impcore eval S397 evaldef $398 typeof 338 = typdef 341 
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a closure, page 122 
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Garbage collection 


A the size of the heap, page 260 

L the amount of live data, page 261 

ay the ratio of heap size to live data (“gamma”), page 262 

Type systems 
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(“cross”), page 348 
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[7] the set of values associated with type 7, page 350 

K a kind, which classifies types (“kappa”), page 354 
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=> used to form kinds of type constructors (“arrow”), page 354 

T 11k ascribes kind x to type 7 (“7 has kind &”), page 354 

A a kind environment (“delta”), page 354 

a,2,y_ type variables (“alpha, beta, gamma”), page 356 

Vv used to write quantified, polymorphic types (“for all”), page 356 

(T1,---,;7) T 7 applied to type parameters 71,..., Tn, page 357 


type equivalence, page 369 


a) set intersection, page 374 

0 the empty set (“empty”), page 374 

Type inference 

oO a type scheme (“sigma”), page 408 

0 a substitution (“THAYT-uh”), page 409 

< the instance relation (“instance of”), page 410 
Or the identity substitution, page 411 

7 ~T' simple type-equality constraint (“7 must equal 7’”), page 418 
C type-equality constraint, page 418 

T the trivial type-equality constraint, page 420 
= equivalence of constraints, page 432 

Abstract data types 


(-:-) bag brackets, page 550 
<i the subtype relation, page 561 
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Introduction 


The implementation exercises, for all my frustration while 
doing them, are tremendously valuable. I find that 
actually implementing something like type inference or 
continuations greatly enhances my understanding of it, 
and testable programs are much easier to play with 

and build intuition about than are pages of equations. 


Russ Cox 


This book is about programming languages—and also about programming. Each of 
these things is made better by the other. If you program but you don’t know about 
programming languages, your code may be longer, uglier, less robust, and harder 
to debug than it could be. If you know about programming languages but you don’t 
program, what is your knowledge for? To know a language is good, but to use it well 
is better. 

What should you know? Not as many languages as possible. Master a few 
language-design ideas of lasting value: learn what they are, how to recognize them, 
and how to use them. Focus on the best the field has to offer. 

The field of programming languages is about more than just programming; 
it offers rigorous, formal techniques for describing all computational processes, 
for analyzing language features, and for proving properties of programs. The for- 
mal tools are used by professionals to communicate their ideas concisely and ef- 
fectively. Practice with formal tools will help you to see past superficial differences 
in programming languages, to recognize old ideas when they appear in new lan- 
guages, to evaluate new programming languages, and to choose and use program- 
ming languages intelligently. But formalism is in second place here; programming 
comes first. 


WHAT YOU WILL LEARN AND HOW 


Programming Languages: Build, Prove, and Compare helps you use programming lan- 
guages effectively, describe programming languages precisely, and understand and 
enjoy the diversity of programming languages. You will learn by experimenting 
with and comparing code written in different languages. You will use important 
programming-language features to write interesting code, understand how each 
feature is implemented, and see how different languages are similar and how each 
one is distinctive. 

You will code in and experiment with small bridge languages, which illuminate 
essential features that you will see repeatedly throughout your career. Each bridge 
language is small enough to learn, but big enough to act as a bridge to the real thing. 
The main bridge languages—Scheme, (sML, Molecule, and pSmalltalk—are rich 
enough to write programs that are interesting, and they are distilled from languages 
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whose greatness is widely acknowledged: designers behind Scheme, ML, CLU, and 
Smalltalk have all won ACM Turing Awards, which is the highest professional honor 
a computer scientist can receive. Their designs have influenced many languages 
that are fashionable today, including Racket, Clojure, Rust, Haskell, Python, Java, 
JavaScript, Objective C, Ruby, Swift, and Erlang. 

Four other bridge languages are suitable for writing toy programs only: Imp- 
core, Typed Impcore, Typed psScheme, and nano-ML are intended for conveying 
ideas, not for programming. 

Allthe bridge languages share the same, simple concrete syntax, in which every 
expression is wrapped in parentheses. Uniform syntax helps you ignore superficial 
differences and focus on essentials. Each bridge language is also implemented by 
an interpreter, which runs the code you write. The interpreter helps you master 
the abstract world of formalism—in each chapter, you can compare mathematical 
descriptions of language ideas with the code that implements those ideas. And you 
can use the interpreters to create your own language designs. Whether your own 
design explores a variation on one of mine or goes in a completely different di- 
rection, trying new design ideas for yourself—and programming with the results— 
will give you a feel for the problems of language design, which you can’t get just by 
studying existing languages. Don't let other people have all the fun! 


The book helps you learn in three ways: 


* Build, and learn by doing. You will learn by building and modifying programs. 
You will write code in the bridge languages, and you will modify the inter- 
preters. 


Once you build things, you may want to share them with others, such as po- 
tential employers. My own students’ work is more than worthy of a profes- 
sional portfolio. But if you share your work using a public site like Github or 
Bitbucket, please share this part of your portfolio only with individuals that 
you name—please don’t put your work in a public repository. 


Prove, to keep things simple and precise. A proof enables an expert to know that 
an optimized program behaves the same as the original, or that no program 
ina safe language can ever result in an unexplained core dump. Practice with 
proof will help you understand what you can and can’t count on from a lan- 
guage and its implementation. Try some exercises in language metatheory 
(Chapter 1), equational reasoning (Chapters 2 and 8), and type-system meta- 
theory (Chapters 6 and 7). 


Compare, and find several ways to understand. We all learn more easily when 
we compare new ideas with what we already know—and with each other. You 
will learn syntax, for example, by seeing it in two forms: concrete and ab- 
stract. (Concrete syntax says how a language is written; it’s something every 
programmer learns. Abstract syntax, which may be newto you, says what the 
underlying structure of a language is; it’s the best way to think about what a 
language can say.) You can compare these two ways of writing one syntax, 
and you can also compare the syntaxes of different languages. The syntax of 
each new bridge language uses a new form only when it is needed to express 
a new feature; if a feature is found in multiple bridge languages, it is written 
using the same syntax each time. Things look different only when they are 
different. 


To learn about the meanings of language constructs, you can compare an in- 
terpreter with an operational semantics. Learning about interpretation and 
operational semantics together is easier than learning about each separately. 


To learn powerful programming techniques, including recursion, higher- 
order functions, and polymorphism, you can compare example programs 
both large and small. At first you'll compare example programs written in 
a single language, but eventually you will also compare examples written in 
different languages. 


You'll accomplish all this by doing exercises. In each chapter, exercises are orga- 
nized by the skills they require or develop, with cross-reference to the most relevant 
sections. And the exercises are preceded by short questions intended for “retrieval 
practice,” which helps bring knowledge to the front of your mind. Doing exercises 
will help you learn how a semantics is constructed, how an interpreter works, and 
most important, how to write great code. Each of these avenues to learning rein- 
forces the others, and you can emphasize what suits you best. 


THE BOOK IN DETAIL 


Don't try to read this book cover to cover. Instead, choose languages and chap- 
ters that work for you. To help you choose, I introduce the languages and chap- 
ters here. The introductions sometimes use jargon like “operational semantics,” 
“polymorphism,” or “garbage collection,” because such jargon tells an expert ex- 
actly what’s here. If you’re not expert yet, don’t worry—there are also some longer 
explanations. And use the figures! Figure I.1 (on the next page) shows how the 
later chapters depend on earlier ones, and Tables I.2 and I.3 summarize, respec- 
tively, the main theory concepts and programming techniques for each language. 
All three, like the book, are divided into two parts: foundational features and fea- 
tures for programming at scale. 


Foundations 


Technical study starts with abstract syntax and operational semantics, which specify 
what a language is and what it does. These specifications are implemented by def- 
initional interpreters. The first specifications and implementation are presented in 
the context of a tiny procedural language, Impcore, which is the subject of Chapter 1. 
Impcore includes the familiar imperative constructs that are found at the core of 
mainstream programming languages: loops, conditionals, procedures, and muta- 
ble variables. Impcore doesn’t introduce any new or unusual language features; 
instead it introduces the professional way of thinking about familiar language fea- 
tures in terms of abstract syntax and operational semantics. Impcore also intro- 
duces the interpreters. 

Using abstract syntax, operational semantics, and a definitional interpreter, 
pScheme (Chapter 2) introduces two new language features. First, it introduces 
S-expressions, a recursive datatype. S-expressions are most naturally processed 
using recursion, not iteration; this change has far-reaching effects on program- 
ming style. uScheme also introduces first-class, nested functions, which are treated 
as values, can be stored in data structures, can be passed to functions, and can 
be returned from functions. Functions that accept or return functions are called 
higher-order functions, and their use leads to a concise, powerful, and distinctive 
programming style: functional programming. Scheme is used to explore simple 
recursive functions, higher-order functions, standard higher-order functions on 
lists, continuation-passing style, and equational reasoning. These new ideas re- 
quire only a handful of new language features and primitive functions: wScheme 
extends Impcore by adding let, lambda, cons, car, cdr, and null?. 
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requisite for which others. 


Figure I.1: Topics and languages in this book 


Impcore and uScheme underlie everything else. The subsequent foundational 
chapters are divided into two independent parts: one focused on memory manage- 
ment and one focused on types. wScheme+ (Chapter 3) extends puScheme with con- 
trol operators: break, continue, return, try-catch, and throw. Control operators 
are supported by a small-step operational semantics and a different style of defini- 
tional interpreter; both are based on a so-called CESK machine, which uses an ex- 
plicit stack for evaluation. The new semantics and interpreter are the primary rea- 
sons to study Chapter 3; you'll learn how exceptions can be implemented, and you'll 
see a semantics that can model interaction and nontermination. And in Chapter 4, 
you can extend the interpreter with garbage collectors. 


Table I.2: Theory and concepts in each bridge language 


Language New theory or concepts 
Impcore Abstract syntax, big-step operational semantics 
pScheme Mutable locations, capturing environment in a closure, 
algebraic laws 
pScheme+ Control operators, small-step semantics, garbage collection 
TypedImpcore Typechecking a monomorphic language . ; 
; ; The book in detail 
Typed wScheme Parametric polymorphism 
nano-ML Type inference using equality constraints ° 
ML Algebraic data types 
Molecule Abstract types, modules, bounded polymorphism, separately 


compiled interfaces, and operator overloading 
pSmalltalk Objects, classes, and inheritance 


Garbage collection enables programs written in Scheme and other safe lan- 
guages to allocate new memory as needed, without worrying about where memory 
comes from or where it goes. Garbage collection simplifies both programming and 
interface design, and it is a hallmark of civilized programming. It supports all the 
other languages in the book. In Chapter 4, you can learn about garbage collection 
by building both mark-and-sweep and copying garbage collectors for ~Scheme+. 
You can even build a simple generational collector. If you master Chapters 1 to 4, 
you will have substantial experience connecting programming-language ideas to 
interpreters. 


Independent of uScheme+ and garbage collection, you can proceed directly 
from pScheme to type systems. Type systems demand a change in the implementa- 
tion language: while C is a fine language for writing garbage collectors, it is not so 
good for writing type checkers or sophisticated interpreters. Such tools are more 
easily implemented in a language that provides algebraic data types and pattern 
matching. The simplest, most stable, and most readily available such language 
is Standard ML, which is used from Chapter 5 onward. To acclimate you to Stan- 
dard ML, Chapter 5 reimplements Scheme using Standard ML. That reimplemen- 
tation provides infrastructure used in subsequent chapters, including chapters on 
type systems. 

In Chapter 6, type systems are presented for two languages: Typed Impcore, a 
monomorphic, statically typed dialect of Impcore, and Typed Scheme, a polymor- 
phic, statically typed dialect of wScheme. Both type systems illustrate formation 
rules, introduction rules, and elimination rules, with connections to logic. And in 
the exercises, both systems can be implemented by type checkers. A type checker 
embodies the rules by using type annotations, on formal parameters and else- 
where, to determine the type of every expression in a program. 

Typed yScheme is super expressive, and its type system, when suitably spe- 
cialized or extended, can describe many real languages, from the simple Hindley- 
Milner types of Standard ML to complex features like Haskell type classes or Java 
generics. But considered as a programming language, Typed Scheme is most un- 
pleasant: it requires a type annotation not just on every function definition, but on 
every use of a polymorphic function. A better approach is to add type annotations 
automatically, using type inference. 
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Table I.3: Programming technique in each bridge language 


Language New programming technique 
Impcore Untyped procedural programming 
puScheme Recursive functions on lists and S-expressions; higher-order 


functions; continuation-passing style 

pScheme+ Coding with break, continue, return, try-catch, throw 

TypedImpcore Typed procedural programming with numbers, arrays, and 
Booleans 

Typed wScheme Polymorphic functions with explicit types and explicit general- 
ization and instantiation 

nano-ML Polymorphic functions with inferred types and implicit gener- 
alization and instantiation 


ML Algebraic data types and pattern matching 
Molecule Abstract data types and modules; operator overloading 
pSmalltalk Control structured using dynamic dispatch and continuations 


Type inference is demonstrated in Chapter 7, using the language nano-ML. 
Nano-ML is derived from untyped juScheme, and it uses almost the same data: 
numbers, symbols, Booleans, lists, and functions. But like Typed psScheme, 
nano-ML is type-safe, and yet it does not need to be annotated—the type of every pa- 
rameter, variable, and function is inferred. Type inference helps make code short, 
simple, reusable, and reliable. And in Chapter 7, you can learn how type infer- 
ence works by implementing it for yourself. I recommend an algorithm based on 
conjunctions of type-equality constraints, which can be solved by unification. 


Programming at scale 


Operational semantics, functions, and types are everywhere. These concepts pro- 
vide a foundation for the second part of the book, which presents mechanisms that 
programmers rely on when working at scale. These mechanisms revolve around 
data abstraction, which hides representations that are likely to change. Data ab- 
straction enables components of large systems to be built independently and to 
evolve independently. 

Representations worth hiding need more ways of structuring data than just 
the arrays, lists, and atomic types found in Typed Impcore, Typed Scheme, and 
nano-ML. To structure arbitrarily sophisticated representations, a language needs 
grouping (like struct), choice (like union), and recursion. All three capabilities 
are combined in inductively defined algebraic data types. In Chapter 8, algebraic 
data types are demonstrated using ;sML. “ML can define algebraic data types and 
can inspect their values using case expressions and pattern matching. These ideas 
are central to languages like Haskell, Standard ML, OCaml, Scala, Agda, Idris, and 
Coq/Gallina. 

Once defined, representations can usefully be hidden using abstract data types, 
objects, or both. In Chapter 9, abstract data types are demonstrated using Molecule, 
which builds on sML’s algebraic data types. Abstract types are defined inside mod- 
ules, and they hide information using types: a representation of abstract type can 
be accessed only by code that is in the same module as the type’s definition. Access 
is controlled by a polymorphic type checker like the one in Typed psScheme. Ab- 


stract types and modules are found in languages as diverse as CLU, Modula-2, Ada, 
Oberon, Standard ML, OCaml, and Haskell. (Molecule is a new design inspired by 
Modula-3, OCaml, and CLU.) 

In Chapter 10, objects are demonstrated using Smalltalk. Objects hide infor- 
mation using names: the parts of an object’s representation can be named only by 
code that is associated with that object, not by code that is associated with other 
objects. Unlike such hybrid languages as Ada 95, Java, C#, C++, Modula-3, Objec- 
tive C, and Swift, Smalltalk is purely object-oriented: every value is an object, and 
the basic unit of control flow is message passing. Any message can be sent to any 
object. Objects are created by sending messages to classes, which are also objects, 
and classes inherit state and implementation from parent classes, which enables 
new forms of code reuse. The mechanisms are simple, but remarkably expressive. 


PARTING ADVICE 


This book is not a meal; it’s a buffet. Don’t try to eat the whole thing. Pick out a 
few tidbits that look appetizing, taste them, and do a few exercises. Digest what 
you've learned, rest, and repeat. If you work hard, then you, like my students, will 
be impressed at how much skill and knowledge you develop, and how you'll be able 
to apply it even to languages you will have never seen before. 


Parting advice 
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An imperative core 


Von Neumann programming languages use variables to 
imitate the computer’s storage cells; control statements 
elaborate its jump and test instructions; and assignment 
statements imitate its fetching, storing, and arithmetic. . . 
Each assignment statement produces a one-word result. 
The program must cause these statements to be executed 
many times in order to make the desired overall change in 
the store, since it must be done one word at a time. 


John Backus, Can Programming Be Liberated from the 
von Neumann Style? 


In your prior programming experience, you may have used a procedural language 
such as Ada 83, Algol 60, C, Cobol, Fortran, Modula-2, or Pascal. Or you may have 
used a procedural language extended with object-oriented features, such as Ada 95, 
C#, C++, Eiffel, Java, Modula-3, Objective C, or Python—although these hybrid lan- 
guages support an object-oriented style, they are often used procedurally. Proce- 
dural programming is a well-developed style with identifiable characteristics: 


* Code is organized into procedures; a procedure is a sequence of commands, 
each of which tells the computer, “do something!” (“Command” is what we 
said in the 1960s; these days, we say “statement.”) A command is executed 
for its effects on the state of the machine; procedures continually change the 
“mutable state” of the machine—the values contained in the various machine 
words—by assignment. 


Each command in a procedure can itself be implemented by another proce- 
dure, and so on; procedures can be designed from the top down using step- 
wise refinement (Wirth 1971). 


Data is processed one word at a time; words are commonly organized into 
arrays or records. An array is typically processed by a loop, and a record 
is typically processed by a sequence of commands; these control constructs 
reflect an element-by-element approach to data processing. Loops are typ- 
ically written using “structured” looping constructs such as for and while; 
recursive procedures are not commonly used. 


Both control and data mimic machine architecture. The control constructs 
if and while combine conditional and unconditional jump instructions 
in simple ways; goto, when present, exposes the machine’s unconditional 
jump. Arrays and records are implemented by contiguous blocks of mem- 
ory. Pointers are addresses; assignment is often limited to what can be ac- 
complished by a single load or store instruction. 
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Mimicking a machine has its advantages: costs can be easy to predict, anda 
debugger can be built by adapting a machine-level debugger. 


The procedural style can be embodied in a language. In this chapter, that language 
is Impcore. Impcore is named for the standard imperative core—assignments, 
loops, conditionals, and procedures—that is found in almost all programming lan- 
guages, including not only “imperative” or “procedural” languages but also many 
“functional” and “object-oriented” languages. Impcore is best explained by exam- 
ple, so let’s start by defining a global variable n, which is initialized to 3: 
12a. (transcript 12a)= 12b> 
-> (val n 3) 
3 


” 


The arrow “-> ” is the interpreter’s prompt; text following a prompt is my input; 
and text on the next line is the interpreter’s response:' 

To continue, let’s define a function, which I’ll name x-3-plus-1. It multiplies a 
number k times 3, then adds 1 to the product: 
12b. (transcript 12a) += 12a 12c> 

-> (define x-3-plus-1 (k) 
(+ (* 3k) 1)) 77 returns 3 * k + 1 

The syntax may look different from what you are used to, including the dashes 
in the function’s name, but before we dive into the differences, let’s compute with 
the variable n and function x-3-plus-1 that I just defined. I use them in a loop 
that tries to reduce n to 1 by halving n when it is even and replacing it with 3n + 1 
when it is odd. (This loop is believed to terminate for any positive n, but at press 
time, no proof is known.) In the loop, each line of Impcore code is commented with 
analogous C code on the right; if you know C, C++, Java, JavaScript, or something 
similar, the comments should help you interpret Impcore’s syntax. 


12c. (transcript 12a) += <12b 2lap 
-> (begin rr 
(while (> n 1) 7 while (n > 1) 
(begin i { 
(println n) ed printf ("%d\n", n); 
(if (= (mod n 2) 0) oie if (n % 2 == 0) 
(set n (/ n 2)) He nen / 2; 
(set n (x-3-plus-1 n))))) 7; else n = x_3_plus_1(n); 3 
n) ra return n; 3 
3 
10 
5 
16 
8 
4 
2 
1 


In these examples, you might notice that 


* Where C uses curly brackets, Impcore uses begin. 
* Impcore doesn’t use else or return keywords. 
* Impcore uses a lot of ugly parentheses, but no commas. 


* Impcore puts operators like +, *, >, =, and / in places that might look strange. 


1Most of the examples in this book are written using the Noweb system for literate programming. Bold 
labels such as 12a identify chunks of examples or code, and pointers such as “12b >” point to subsequent 
chunks. Noweb is explained more fully in Section 1.6 on page 39. 


Impcore, like every other language in this book, uses fully parenthesized, prefix syn- 
tax, in which each operator precedes its arguments. C uses infix syntax; each bi- 
nary operator appears between its arguments. In C’s infix syntax, order of evalua- 
tion is determined by “operator precedence,’ which is fine for stuff you use every 
day—but not so good when you have to figure out whether & and && have the same 
precedence and where they both stand with respect to |. In Impcore’s prefix syntax, 
order of evaluation is determined by parentheses; it might be ugly, but you don't 
have to remember any operator precedence. Prefix parenthesized syntax, which is 
used in Scheme, Common Lisp, Emacs Lisp, Racket, Clojure, and the many other 
languages of the Lisp family, puts every operator and every programmer on the 
same footing—the parentheses eliminate any possible ambiguity. 

These examples show Impcore, which is going to help us look at programming 
languages in a deep, systematic way. But first, let’s get the big picture of what as- 
pects we will look at. 


1.1 LOOKING AT LANGUAGES 


A program is ultimately formed from the individual characters of its code. And 
before code runs, it passes through several different phases, each of which is gov- 
erned by its own rules. Phases and their rules can be hard to identify, but for any 
programming language, three sets of rules are essential. They tell us 


* How code is formed 
* What checking it undergoes before it is deemed OK to run 


* What happens when it runs 


To highlight these rules, let’s look at some code that breaks them. Because some of 
the rules involve type checking, we'll look at some C code. (If C is not so familiar, 
try thinking about Java, which has the same kinds of rules.) 

Imagine that I have a two-dimensional point on the plane, and that I want to 
add 3 to its x coordinate. In C, a point p can be defined like this: 


struct { int x; int y; 3 p; 


To add 3 to p’s x coordinate, I write an assignment statement. But if a letter x is 
deleted by a cat that walks across my keyboard, the cat might leave this code: 


p. = p.x + 3; 


This code is rejected by the C compiler, which reports a syntax error. The compiler 
might flag the = sign after the dot, where it would prefer a name. The code is ill 
formed. 

I know I want the = sign, and if I’m programming after midnight, I might just 
remove the dot: 


p=p.x + 3; 


This code is well formed, but a C compiler will report a type error: p is not the type 
of thing you can assign a number to. The code is ill typed. 
The code I meant to write is 


p.X = p.x + 3; 


This code is well formed and well typed, and the compiler is happy. But a happy 
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compiler doesn’t guarantee a happy program. Suppose I write 


int n = 0; 
p.x =p.x / n; 


This code is also well formed and well typed, so it makes the compiler happy, but 
when it runs, nothing good will happen. The best I can hope for is that my operating 
system will report a run-time error, maybe a “floating-point exception.” (The exam- 
ple exhibits what the C standard calls “undefined behavior,’ which the system is 
not obligated to report.) The code is ill behaved. 

Useful code is well formed, well typed, and well behaved. Learning precisely 
what that means, for several different languages, is half of this book. (The other half 
is learning how to use the languages effectively.) The key concepts are as follows: 


* Code is formed according to two sets of rules: Characters are clumped into 
groups called tokens according to lexical rules, and tokens are grouped into 
definitions, statements, and so on according to syntactic rules. The syntactic 
rules are the important ones. Syntax is so important that we talk about two 
varieties: concrete syntax, which is how we write the code, and abstract syntax, 
which is how we think about the code’s structure. Impcore’s concrete and 
abstract syntax are presented in Sections 1.2 and 1.3, respectively. 


Although there are myriad ways that code can be checked before it is deemed 
OK to run, the most practical method is type checking, which follows the rules 
of a static type system. Impcore does not have a static type system; type check- 
ing and its companion, type inference, are not explored in depth until Chap- 
ters 6 and 7. 


* The behavior of running code is specified by its semantics (sometimes called 
dynamic semantics). Semantics can be written in several different styles, 
but this book uses operational semantics, a style that has dominated the field 
since the 1990s. Operational semantics has a learning curve, and to help you 
climb it, each language in this book is implemented by an interpreter. The in- 
terpreter demonstrates what the language’s semantics is trying to tell us, and 
by enabling us to run code, it also helps us learn to use the language effec- 
tively. 


The operational semantics of Impcore is presented in Section 1.5. In Sec- 
tion 1.6, the operational semantics is used to guide the construction of Imp- 
core’s interpreter, and in Section 1.7, the operational semantics is used to 
prove properties of Impcore code. 


To understand any language’s operational semantics or type system, you must 
first know how its programs are formed. To learn, try this approach: 


1. Understand the lexical structure, especially of things like comments and 
string literals. 


2. Look for familiar syntactic categories (page 16), like definitions, declarations, 
statements, expressions, and types. 


3. In each category, look for familiar forms: loops, conditionals, function appli- 
cations, and so on. To identify what’s familiar, mentally translate concrete 
syntax into abstract syntax. 


This approach calls for an understanding of lexical structure, grammars, and the 
two varieties of syntax. 


Lexical structure 


Lexical structure rarely requires much thought. If you can spot comments, string 
literals, and token boundaries, you're good to go. For example, in C, you need to 
see 3*n+1 as 5 tokens, "3*n+1" as a single token (a string literal), and /*3*n+1*/ as 
no tokens at all (just a comment). In this book’s bridge languages, a comment be- 
gins with a semicolon, there are no string literals, and token boundaries are found 
only at brackets or whitespace. For example, in Impcore, 3*n+1 is a single token 
(a name). 


Grammars 


Concrete syntax is specified using a grammar, which tells us what sequences of to- 
kens are well formed. For example, the following toy grammar shows four ways to 
form an expression exp: 


exp ::= variable-name | numeral | exp + exp | exp * exp. 


The grammar says that an expression may be a variable, a numeral, the sum of two 
expressions, or the product of two expressions. Each alternative is a syntactic form. 

This grammar, like any grammar, can be used to produce an expression by re- 
placing exp with any of the four alternatives on the right-hand side, and continuing 
recursively until every exp has been replaced with a variable or a numeral. For ex- 
ample, the C expression 3 * n + 1 can be produced in this way. 

The toy grammar is compositional: big expressions are made by composing 
smaller ones. Every interesting programming-language grammar supports some 
kind of composition; even an assembly language allows you to compose long se- 
quences of instructions by concatenating shorter sequences. Compositional syn- 
tactic structure is part of what makes something a programming language. More 
compositional structure can be found in the grammar for Impcore (page 18). 


Two varieties of syntax 


When we write concrete syntax, we should be thinking about abstract syntax. For ex- 
ample, concrete syntax tells us that the “3n + 1” loop is written using a while key- 
word, and that in C the loop condition goes between round brackets (parentheses). 
But we should be thinking “while loop with a condition and a body,” which is what 
abstract syntax tells us: it names the form (WHILE) and says that a WHILE loop is 
formed from an expression (the condition) and a statement (the body). Abstract 
syntax ignores syntactic markers like keywords and brackets. 

Abstract syntax helps us recognize familiar forms even when they are clothedin 
unfamiliar concrete syntax. For example, you can probably recognize loops written 
in C, Icon, Impcore, Python, Modula-3, Scala, and Standard ML: 


while (n> 1) n=n/ 2; 

while n> 1don:=n/e2 
(while (> n 1) (set n (/ n 2)) 
while n> i: n=n/e2 

WHILE n > 1 DO n :=n / 2 END 
while (n > 1) § n=n / 2; 3 
while !n > 1 don := !n div 2 


Each language uses a different concrete syntax, but abstract syntax provides a kind 
of X-ray vision: under their clothes, all these loops are the same. 

Abstract syntax is not just a tool for thought. It also gives us abstract-syntax 
trees, the data structure used to represent code in most compilers and interpreters. 
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In this book, abstract-syntax trees appear in C code (Chapters 1 to 3) and in Stan- 
dard ML code (Chapters 5 to 10). Abstract syntax also provides a compact notation 
for operational semantics and type systems. Using such a notation, all the while 
loops above would be written the same way: WHILE(e, s), where e stands for the 
condition and s stands for the body. 


Familiar syntactic categories and forms 


Abstract syntax is rarely specified explicitly; you'll almost always infer it by read- 
ing a grammar that describes concrete syntax. A real grammar will have many 
left-hand sides like exp; these symbols are called nonterminal symbols, or just non- 
terminals. Sometimes the nonterminals tell you exactly what the important phrases 
in a language are, but if the grammar has been engineered primarily to help a com- 
piler to convert its input into an abstract-syntax tree, many nonterminals will be 
annoying or distracting. For example, a nonterminal like explist1 (a list of one or 
more expressions separated by commas) adds nothing to our understanding. 

To understand the structure of a grammar, search the nonterminals for syntactic 
categories. A syntactic category is a group of syntactic forms that share an important 
role; for example, the role of an expression is to be evaluated to produce a value 
(and possibly also have a side effect). Typically, two phrases in the same syntactic 
category can be interchanged without affecting the well-formedness of a program. 
For example, any of these expressions could be used on the right-hand side of the 
assignment to p.x: 


p.x +3 p.x /n p->next 2*p 


Assigning any of these expressions to p.x would be well formed, but as shown 
above, the division p.x /n might not be well behaved, and the assignments of 
p->next and 2 * p aren't well typed. 

Syntactic categories aren't arbitrary, and in any programming language, there 
are at least four common categories worth looking for: 


* A definition introduces a new thing and gives it a name. Forms to look for 
include forms that define functions, variables, and maybe types; Impcore 
marks its function-definition and variable-definition forms with keywords 
define and val. 


A declaration introduces a new thing, with a name, but doesn’t yet define 
the thing—instead, a declaration promises that the thing is defined else- 
where. Because anything that can be declared eventually has to be defined, 
the forms to look for are forms for declaring things that can be defined. 
In C and C++, declaration forms are mostly found in .h files. Impcore has 
no declaration forms; in this book, declaration forms aren't used until Chap- 
ter 9. 


+ An expression is evaluated to produce a value, and possibly also have a side ef- 
fect. Forms to look for include variables, literal values, function applications, 
maybe infix operators, and hopefully a conditional form (like C’s ternary ex- 
pression €1 ? €2 : €3). Impcore has all these forms except infix operators. 


+ A statement is executed for side effect; it doesn’t produce a value. Side effects 
might include printing, changing the value of a variable, or changing some 
value in memory, among others. Forms to look for include loops (while, for), 
conditionals (if), sequencing (begin), and if you’re lucky, a case or switch 
statement. Impcore doesn’t actually have statements; its while and if forms 
are expressions. 


Impcore’s lack of statements might surprise you, but it’s a well-known design 
choice. Providing loops and conditionals as expressions, not statements, makes 
a language expression-oriented. All functional languages are expression-oriented; 
among procedural languages, Icon is expression-oriented (Griswold and Griswold 
1996); and among languages with object-oriented features, Scala is expression- 
oriented (Odersky, Spoon, and Venners 2019). Making a language expression- 
oriented simplifies the syntax a bit; for example, an expression-oriented language 
needs only one conditional form, whereas a language like C has both a conditional 
statement and a conditional expression. 

With your eye out for familiar definition and expression forms, you’re ready to 
be fully introduced to Impcore. 


1.2 THE IMPCORE LANGUAGE 


An Impcore program is a sequence of definitions, each of which contains at least 
one expression. Definitions come in two main forms: a definition of a variable, such 
as (val n5), and a definition of a function, such as (define double (x) (+x x)). 
Impcore is implemented by an interactive interpreter, and because it’s wonderfully 
convenient to be able to type in an expression, have it evaluated, and see the result, 
Impcore also counts an expression, such as (+ 2 2), as a “definition’—in this case, a 
definition of the global variable it. The global variable it thereby “remembers the 
last expression typed in.” (The variable it has played this special role in interactive 
interpreters for over thirty years.) 

With the big picture of definitions and expressions in mind, we're ready to 
look at the complete lexical and syntactic structure of Impcore—how programs are 
formed—and some more examples. 


1.2.1 Lexical structure and concrete syntax 


Impcore fits the model described on page 14: the rules for forming programs are 
divided into lexical rules and syntactic rules. The lexical rules, with only minor 
variations, are the same for all the languages in the book: 


* Asemicolon starts a comment, which runs to the end of the line on which it 
appears. 


* Each bracket character—(, ), [, ], £, or }—is a token by itself. Impcore uses 
only the round and square brackets, not the curly ones. 


* Other characters are clumped into tokens that are as long as possible; a token 
ends only at a bracket, a semicolon, or whitespace. 


* Aside from its role in delimiting tokens, whitespace is ignored. 


If you’re used to C or Java, these rules may surprise you in a one small way: inputs 
like x+y and 3rd are single tokens—in Impcore, each is a valid name! 

In this book, syntactic rules—that is, grammars—are written using Extended 
Backus-Naur Form, usually abbreviated as EBNF. EBNF is based on plain BNF, 
which is ubiquitous. BNF has been extended in many different ways, and the EBNF 
I use is best understood through an example: the grammar for Impcore, which ap- 
pears in Figure 1.1 on the next page. (ENBF is explained more fully in Appendix A.) 

Figure 1.1, like any other grammar, lists nonterminal symbols like def, unit-test, 
exp, and so on. Each nonterminal is followed by the ::= symbol (pronounced “pro- 
duces”), followed by the forms of the phrases that the nonterminal can produce. 
Alternative forms are separated by vertical bars, as (one thing | another). In each 
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def i= (val variable-name exp) 

exp 

(define function-name (formals) exp) 
(use file-name) 

unit-test 


unit-test i= (check-expect exp exp) 
(check-assert exp) 
(check-error exp) 


exp = literal 

variable-name 

(set variable-name exp) 
(if exp exp exp) 

(while exp exp) 

(begin { exp} ) 
(function-name { exp} ) 


formals = { variable-name} 
literal = numeral 
numeral _—::= token composed only of digits, possibly prefixed with a plus 


or minus sign 


any *-name ::= token that is not a bracket, a numeral, or one of the “re- 
served” words shown in typewriter font 


Any syntactic form that is written with a matching pair of round brackets (-- - ) 
may equally well be written with a matching pair of square brackets [ -- - ]. They 
mean the same. 


Figure 1.1: Concrete syntax of Impcore 


syntactic form, a token that is supposed to appear literally (like val or while) is 
written in typewriter font; a name that stands for a token or for a sequence of 
tokens (like def, variable-name, or exp) is written in italic font. Finally, a phrase 
that can be repeated is written in curly brackets, like the { exp} in the begin form; 
a begin may contain any number of exps, including zero. 

Figure 1.1 confirms that Impcore’s concrete syntax is fully parenthesized; wher- 
ever a sequence of tokens appears, that sequence is wrapped in brackets. You may 
find this syntax unattractive, especially in complex expressions. But when you're 
learning multiple languages, it’s great not to have to worry about operator prece- 
dence. And when you must write a deeply nested expression with a ton of brackets, 
you can reveal its structure by mixing round and square brackets—as long as round 
matches round and square matches square, the two shapes are interchangeable. 

Figure 1.1 begins with definitions. The definition form (val x e) defines a new 
global variable x and initializes it to the value of the expression e. A global variable 
must be defined before it is used or assigned to. Next, any expression exp may be 
used as a definition form; it defines or assigns to the global variable it. And the def- 
inition form (define f (41 --- Zp») e) defines a function f with formal parameters 
x1 to Ly and body e. 

The val, exp, and define forms are what I call true definitions; these forms 
should be thought of as part of a program. The remaining forms, which I call ex- 
tended definitions, are more like instructions to the interpreter. The (use file-name) 


form tells the interpreter to read and evaluate the definitions in the named file. 
A check-expect, check-assert, or check-error form tells the interpreter to re- 
member a test and to run it after reading the file in which the test appears. 

The expression forms, which all appear in the example while expression at the 
beginning of the chapter, constitute a bare minimum needed for writing impera- 
tive or procedural code. The forms can express a literal value, a variable, an assign- 
ment (set), a conditional (if), a loop (while), a sequence (begin), and a function 
application (any other bracketed form). 

Variables and functions are named according to liberal rules: almost any non- 
bracket token can be a name. Only the words val, define, use, check-expect, 
check-assert, check-error, set, if, while, and begin, are reserved—they cannot 
be used to name functions or variables. And a numeral always stands for a number; 
a numeral cannot be used to name a function or a variable. 

When Impcore starts, some names are already defined. These include prim- 
itive functions +, -, *, /, =, <, >, println, print, and printu, and also predefined 
functions and, or, not, <=, >=, !=, mod, and negated. A set of defined names forms 
a basis; the set of names defined at startup forms the initial basis. The concepts of 
primitive, predefined, and basis are explained in Section 1.2.6 (page 26). 


1.2.2 Talking about syntax: Metavariables 


Once we know how code is formed, we can talk about what happens when it is run. 
To talk about any well-formed code, not just particular codes, we use names called 
metavariables. In this chapter, the metavariables used to talk about code are as fol- 
lows: 


Any expression 

Any definition 

Any numeral 

Any name that is meant to refer to a variable or a parameter 
Any name that is meant to refer to a function 


SS 3A 


To talk about more than one expression or name, we use subscripts. For example, 
we write an if expression as (if €1 €2 €3). Because each subexpression might be 
different from the other two, each one is referred to by its own metavariable. 

Metavariables are distinct from program variables. Program variables appear in 
source code; metavariables stand for source code. Metavariables are written in 
math italics and program variables in typewriter font. For example, x is a pro- 
gram variable: it is a name that can appear in source code. But x is a metavariable: 
it stands for any name that could appear in source code. Metavariable x might 
stand for x, but it might also stand for y, z, i, j, or any other program variable. 
To illustrate the difference, when we write (val x 3), we mean the definition of 
global program variable x. But when we write (val x e), we mean a template that 
can stand for any definition of any global variable. 

Metavariables differ from program variables in one other crucial respect: 
a metavariable can’t be renamed without changing its meaning. So although you 
can write (define double (n) (+nn)) and it means exactly the same thing as 
(define double (x) (+x x)), you cannot write (val mg) and have it mean the 
same thing as (val xe): (val x e) is a template for an expression, but because 
mand g mean nothing when used as metavariables, (val m q) is gibberish. If you 
want a distinct name for a new metavariable, the most you can do is decorate the 
original name in some way—traditionally with a prime or a subscript. For example, 
(val 2’ e4) is also a template for an expression, and it’s an expression that might 
be different from (val x e). 
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* To evaluate a literal expression, which in Impcore takes the form of 
a numeral n, we return the 32-bit integer that n stands for. 


* To evaluate an expression that takes the form of a variable name z, 
we find the variable that x refers to, which must be be either a func- 
tion parameter or a global variable defined with val, and we return 
the value. 


* To evaluate an expression of the form (set x e), we evaluate e, as- 
sign its value to the variable x, and return the value. Variable x must 
be a global variable or a formal parameter. 


* To evaluate an expression of the form (if e1 €2 e3), we first evalu- 
ate e,. If the result is nonzero, we evaluate e2 and return the result; 
otherwise we evaluate e3 and return the result. 


* To evaluate an expression of the form (while e; e2), we first evalu- 
ate €;. If the result is not zero, we evaluate €2, then start evaluating 
the loop again with e;. We continue until e; evaluates to zero. When 
€; evaluates to zero, looping ends, and the result of the while loop 
is zero. (The result of evaluating a while expression is always zero, 
but because while is typically evaluated for its side effects, we usu- 
ally don’t care.) 


* To evaluate an expression of the form (begin €, --- €,,), we evalu- 
ate expressions €; through e,, in that order, and we return the value 
of €n. 


* To evaluate an expression of the form (f €1 --- en), we evaluate ex- 
pressions e; through e,, in that order, calling the results 11,..., Un. 
We then apply function f to v1,..., Un, and return the result. Func- 
tion f may be primitive or user-defined; if f names a user-defined 
function, we find f’s definition, let the names in the formals stand for 
U,,--+,Uny and return the result of evaluating f’s body. If f names 
a primitive function, we apply it as described Section 1.2.4 (page 23). 


Figure 1.2(a): Rules for evaluating expressions 


1.2.3 What the syntactic forms do 


Metavariables enable us to talk about any definition or expression of a certain form. 
And what we most want to say is operational: what happens when a form is evalu- 
ated. To explain the evaluation of Impcore’s syntactic forms, I want to draw on your 
experience and intuition, so I use informal English. But informal English lacks pre- 
cision, so in Section 1.5 (page 29), I also provide a precise, formal semantics. 

I start with the most fundamental syntactic category: expressions. When an 
expression is evaluated, it returns a value. A value is not code, so to refer to a value, 
we need another metavariable: 


uv Any value 


In Impcore, all values are integers. Evaluating an expression produces a value and 
may also have a side effect; in Impcore, possible side effects include printing some- 
thing or changing the value of a variable. 


A literal 3 evaluates to the value 3. 

21a. (transcript 12a) += <12c 21bp 
—-> 3 
3 

The global variable n defined earlier in the chapter evaluates to its value: 


21b. (transcript 12a) += d2la 21e> 
-> n 
1 

A set changes a variable’s value: 

21c. (transcript 12a) += <21b 21d> 
-> (set n -13) 
-13 


A conditional evaluates to a value that depends on the condition. For ex- 
ample, a conditional can compute the absolute value of n: 
21d. (transcript 12a) += <21c 2le> 
-> (if (< n 0) (negated n) n) 
13 
A loop’s value is always 0, but its evaluation can change the values of vari- 
ables: 
21e. (transcript 12a) += 21d 21f> 
-> (while (<n 0) (set n (+ n 10))) 
0 
-> n 
7 
A begin is used to sequence expressions for their side effects, like 
printing: 
21f. (transcript 12a) += d2le 21g> 
-> (begin (printu 169) (println 2021) -1) 
02021 
=1 
Function application may call a primitive, predefined, or user-defined 
function, like <, negated, +, printu, println, or x-3-plus-1. 


Figure 1.2(b): Examples of evaluating expressions 


Expressions are evaluated according to the rules in Figure 1.2(a), and corre- 
sponding examples appear in Figure 1.2(b)—except for calls and names, because 
examples of calls and names won't fit in the figure. To illustrate calls and names, 
I show what the Impcore interpreter does with two function definitions and calls. 
After evaluating a function’s definition, the interpreter echoes the function’s name. 


21g. (transcript 12a) += 21f 22ap 
-> (define addi (n) (+ n 1)) 
addi 
-> (define double (n) (+n n)) 
double 
-> (add1 4) 
5 
-> (double (+ 3 4)) 
14 
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A user-defined function is called much as in C: first the arguments are evaluated; 
their values are the actual parameters. Then the function's body is evaluated with 
each actual parameter “bound to” (which is to say, named by) the corresponding 
formal parameter from the formals in the function's definition. In the first example, 
the actual parameter is 4, and (+n 1) is evaluated with 4 bound to n. In the second, 
the actual parameter is 7, and (+ nn) is evaluated with 7 bound to n. 

In Impcore, a function call behaves nicely only if the number of actual param- 
eters is exactly equal to the number of formal parameters in the function's defini- 
tion. Otherwise, the call goes wrong: 
22a. (transcript 12a) += 21g 22bp 

-> (addi 17 12) 
Run-time error: in (addi 17 12), expected 1 argument but found 2 


In our examples so far, as in C, the name n means different things in differ- 
ent contexts. For example, functions addi and double use the name n as a formal 
parameter, and inside each function, n refers to that parameter. But outside any 
function, n continues to refer to the global variable defined on page 12. The mean- 
ing of any occurrence of any name is determined by the context in which the name 
occurs: If a variable x occurs in a function definition, and if the function has a 
formal parameter named with the same z, then z refers to that formal parameter. 
Otherwise x refers to a global variable. (Impcore has no local variables; to provide 
them is the object of Exercise 30.) If x occurs in a top-level expression, outside of 
any function definition, it necessarily refers to a global variable. 

Let’s contrive an example: 
22b. (transcript 12a) += 22a 23ap 

etal 7; the global n 

7 

-> (define addn (n m) (set n (+ n m))) 7; mutates the parameter 
addn 

-> (addn n 1) ;; the parameter is set to 8 
8 

>on 7; the global n is unchanged 
7 


Within the body of addn, the two occurrences of nrefer to the formal parameter. But 
in the top-level expressions n and (addn n 1), n refers to the global variable. And in 
the body of addn, where n is set, changing the formal n does not affect anything in 
the calling context; we say that Impcore passes parameters by value. No assignment 
to a formal parameter ever changes the value of a global variable. 

With the details of expressions explored, we turn our attention to definitions. 
When a definition is evaluated, no value is returned; instead, evaluating a definition 
updates some part of the interpreter’s state, causing it to “remember” something. 
The Impcore interpreter can remember global variables, function definitions, and 
pending unit tests. 


* To evaluate a definition of the form (val x e), we first check to see if a global 
variable named «x exists, and if not, we create one. We then evaluate e and 
assign its value to x. 


* To evaluate a definition that takes the form of an expression e, we evaluate e 
and store the result in the global variable it. 


* To evaluate a definition of the form (define f (x1 --- X,,) e), like the defi- 
nitions of add1 or double, we remember /f asa function that takes arguments 
Y1,.--,%n and returns e. 


* To evaluate a definition of the form (use filename), we look for a file called 
filename, which should contain a sequence of Impcore definitions. We read 
the definitions and evaluate them in order. And after reading the file, we run 
any unit tests it contains. 


To evaluate a definition of the form (check-expect e€, €2), we remember this 
test: at the end of the file containing the definition, evaluate both e; and e2. 


If their values are equal, the test passes; if not, the test fails. §1.2 
The Impcore 
To evaluate a definition of the form (check-assert e), we remember this language 


test: at the end of the file containing the definition, evaluate e. If its value is 
nonzero, the test passes; if not, the test fails. 
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To evaluate a definition of the form (check-error e), we remember this test: 
at the end of the file containing the definition, evaluate e. If evaluating e 
triggers a run-time error, like dividing by zero or passing the wrong number 
of arguments to a function, the test passes; if not, the test fails. 


1.2.4 What the primitive functions do 


Not every function is defined using define; some are built into the interpreter as 
primitives. Each primitive function takes two arguments, except the printing primi- 
tives, which take one each. The arithmetic primitives +, -, *, and / do arithmetic on 
integers, up to the limits imposed by a 32-bit representation. Each of the compari- 
son primitives <, >, and = does a comparison: if the comparison is true, the primi- 
tive returns 1; otherwise, it returns 0. 

The printing primitives demand detailed explanation. Primitive print1n prints 
a value and then a newline; it’s the printing primitive you'll use most often. Prim- 
itive print prints a value and no newline. Primitive printu prints a Unicode char- 
acter and no newline. More precisely, printu takes as its argument an integer that 
stands for a Unicode code point—that means it’s an integer code that stands for a 
character in one of a huge variety of alphabets. Primitive printu then prints the 
UTF-8 byte sequence that represents the code point. In most programming envi- 
ronments, this sequence will give you the character you're looking for. For exam- 
ple, (printu 955) prints the Greek letter \. Each printing primitive, in addition to 
its side effect, also returns its argument. 

When used interactively, the printing primitives can be confusing, because 
whenever an expression is evaluated, its value is printed automatically by the in- 
terpreter. Don't be baffled by effects like these: 
23a. (transcript 12a) += <22b 23b> 

-> (val x 4) 
-> (printin x) 
4 


4 
addi 21g 


The 4 is printed twice because print1n is called with actual parameter 4 (the value 
of x), and print1n first prints 4, accounting for the first 4, then returns 4. The sec- 
ond 4 is printed because the interpreter prints the value of every expression, in- 
cluding (println x). 


2ab. (transcript 12a) += 23a 24ab 
-> (val y 5) 
5 
-> (begin (println x) (println y) (* x y)) 
4 
5 
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True definitions and extended definitions: A design compromise 


If you want to learn to use programming languages well and also to describe 
them precisely, what languages should you study? Not big industrial languages— 
you can write interesting programs, but it’s hard to say how programs behave, 
or even what programs are well behaved. And not a tiny artificial language (ora 
“core calculus” like the famous lambda calculus)—its behavior can be described 
very precisely, but it’s hard to write any interesting programs. That’s why I’ve 
designed the bridge languages: to bridge the gap between industrial languages 
and core calculi. 


The bridge languages are small enough to be described precisely, but big 
enough for interesting programs. (I won't pretend you can write interesting pro- 
grams in Impcore, but you can write interesting programs in Scheme, psML, 
Molecule, and ywSmalltalk.) But a few features are too complicated to define 
precisely, yet too useful to leave out. They are the “extended definitions”: the 
use, check-expect, check-assert, and check-error forms. The val, define, 
and top-level expression forms, which are defined precisely, are the “true def- 
initions.” The true definitions are part of the language, and the extensions are 
there to make you more productive as a programmer. 


If you happen to use print instead of print1n, you can get some strange output: 
24a. (transcript 12a) += <123b 25b> 
-> (begin (print x) (print y) (* x y)) 
4520 
Because the interpreter automatically prints the value of each expression you 
enter, you'll use printing primitives rarely—mostly for debugging. I typically debug 
using printin, but when I want fancier output, I also use printu and print. 


1.2.5 Extended definitions: Beyond interactive computation 


The examples above show transcripts of my interactions with the Impcore inter- 
preter. But interactive code disappears as soon as it is typed; to help you write code 
that you want to edit or keep, the Impcore interpreter, like all the interpreters in 
this book, enables you to put it in a file. And when you put code in a file, you can 
add unit tests. For example, the file gcd. imp tests a function that computes greatest 
common denominators: 
24b. (contents of file gcd.imp 24b)= 25a> 
(val r 0) 
(define gcd (m n) 
(begin 
(while (!= (set r (mod mn)) 0) 
(begin 
(set mn) 
(set nr))) 
n)) 


(check-expect (gcd 6 15) 3) 


Since the code is in a file, there are no arrow prompts. But there is a unit test, 
our first: the check-expect says that if we call (gcd 6 15), the result should be 3. 


The file includes more unit tests: 
25a. (contents of file gcd. imp 24b) += <124b 
(check-expect (gcd 15 15) 15) 
(check-expect (gcd 14 15) 1) 
(check-expect (gcd 14 1) 1) 
(check-expect (gcd 72 96) 24) 
(check-error (gcd 14 0)) 
The last unit test says that if we evaluate (gcd 14 0), we expect a run-time error. 

Unit tests aren’t run until after a file is loaded. Then the interpreter summarizes 
the test results: 
25b. (transcript 12a) += 24a 25dp 

-> (use gcd.imp) 

0 

gcd 

All 6 tests passed. 

A unit test can appear before the function it tests. This trick can be a great way 
to plan a function, or to documentit. I’ve written an example using triangular num- 
bers. A triangular number is analogous to the square of anumber: just as the square 
of n is the number of dots needed to form a square array with a side of length n, the 
nth triangular number is the number of dots needed to form an equilateral triangle 
with n dots along one side. 


1 — * 
3 = * 
* * 
* 
6 = * OX 
* *K Xx 


A triangular number can be computed using the sigma function in Exercise 2 on 
page 74, but there’s a shortcut: 
25c. (triangle.imp 25c)= 

(check-expect (triangle 1) 1) 

(check-expect (triangle 2) 3) 

(check-expect (triangle 3) 6) 

(check-expect (triangle 4) 10) 


(define triangle (n) 
(/ (Fn (+ 1 1)) 2)) 


25d. (transcript 12a) += <25b 26aD 
-> (use triangle.imp) 
triangle 
All 4 tests passed. 


mod 


When writing triangle, I botched my first attempt. My unit tests caught the 
botch. The botched code, preceded by tests, looked like this: 


25e. (botched-triangle.imp 25e)= 
(check-expect (triangle 1) 1) 
(check-expect (triangle 2) 3) 
(check-expect (triangle 3) 6) 
(check-expect (triangle 4) 10) 


(define triangle (n) ; botched version 


(/ (Fn (- n 1)) 2)) 
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The unit tests caught the botch: 

26a. (transcript 12a) += 25d 26c> 
-> (use botched-triangle.imp) 
triangle 
Check-expect failed: expected (triangle 1) to evaluate to 1, but it's 0. 
Check-expect failed: expected (triangle 2) to evaluate to 3, but it's 1. 
Check-expect failed: expected (triangle 3) to evaluate to 6, but it's 3. 
Check-expect failed: expected (triangle 4) to evaluate to 10, but it's 6. 
All 4 tests failed. 


The check-expect form provides what you'll need to test most Impcore code: 
because every Impcore value is an integer, your unit tests can usually just say 
what value you expect. But in Chapter 2 and beyond, you'll have access to more 
structured values, like records and lists, and you'll want to talk about properties, 
like “the list is sorted.” For that purpose, each of the bridge languages includes a 
check-assert form, which is intended for use with Booleans. As examples, here 
are a few assertions about properties of products. 
26b. (arith-assertions.imp 26b) = 

(check-assert (< (* 1 2) (+ 1 2))) ; product is smaller than sum 
(check-assert (> (¥* 2 3) (+ 2 3))) 7 product is bigger than sum 
(check-assert (not (< (* -1 -1) 0))) ; product of negatives is not negative 


Function not is predefined; its definition appears in Figure 1.3 (page 27). 
26c. (transcript 12a) += 26a 29> 


-> (use arith-assertions.imp) 
All 3 tests passed. 


1.2.6 Primitive, predefined, and basis; the initial basis 


Programmers like big languages with lots of data types and syntactic forms, but 
implementors want to keep primitive functionality small and simple. (So do se- 
manticists!) To reconcile these competing desires, language designers have found 
two strategies: translation into a core language and definition of an initial basis. 

Using a core language, you stratify your language into two layers. The inner 
layer defines or implements its constructs directly; it constitutes the core language. 
The outer layer defines additional constructs by translating them into the core lan- 
guage; these constructs constitute syntactic sugar. In this chapter, the core language 
is Impcore, and as an example of syntactic sugar, a for expression can be defined 
by a translation into begin and while (Section 1.8). 

To be useful to programmers, a language needs to be accompanied by a stan- 
dard library. In the theory world, a library contributes to a basis; basis is the col- 
lective term for all the things that can be named in definitions. In Impcore, these 
things are functions and global variables. A language’s initial basis contains the 
named things that are available in a fresh interpreter or installation—the things 
you have access to even before evaluating your own code. 

Like the Impcore language, Impcore’s initial basis is stratified into two layers, 
one of which is defined in terms of the other. The inner layer includes all the func- 
tions that are defined directly by C code in the interpreter; these are called primi- 
tive. The outer layer includes functions that are also built into the interpreter, but 
are defined in terms of the primitives using Impcore source code; they are user- 
defined functions and are called predefined. 

Stratifying the initial basis makes life easy for everyone. Implementors make 
their own lives easy by defining just a few primitives, and they can make program- 
mers’ lives easy by defining lots of predefined functions. Predefined functions are 


Boolean connectives are defined using if expressions. 

27a. (predefined Impcore functions 27a)= 27b> 
(define and (b c) (if bc b)) 
(define or (bc) (if b bc)) 
(define not (b) (if b 0 1)) 


Unlike the similar constructs built into the syntax of many languages, these ver- 
sions of and and or always evaluate both of their arguments. Section G.7 shows 
how you can use syntactic sugar to define short-circuit variations that evaluate a 
second expression only when necessary. 
Only comparisons <, =, and > are primitive; the others are predefined. 
27b. (predefined Impcore functions 27a) += <127a 27¢c> 
(define <= (x y) (not (> x y))) 
(define >= (x y) (not (< x y))) 
(define != (x y) (not (= x y))) 
Primitive arithmetic includes +, -, *, and /, to which the predefined functions 
add modulus and negation. 
27c. (predefined Impcore functions 27a) += <127b 
(define mod (mn) (- m (* n (/ mn)))) 
(define negated (n) (- 0 n)) 


These functions are installed into the initial basis by the C code in chunk (install 


the initial basis in functions $297b), which is continued in chunk $2974. 


Figure 1.3: Predefined functions in Impcore’s initial basis 


just ordinary code, and writing them is lots easier than defining new primitives. 
Impcore’s predefined functions are defined by the code in Figure 1.3. 

Just like any other function, a primitive or predefined function can be redefined 
using define. This trick can be useful—for example, to count the number of times 
a function is called. But if you redefine an initial-basis function, don’t change the 
results it returns! (You'll introduce bugs.) 

Before going on to the next sections, work some of the exercises in Sec- 
tions 1.10.2 to 1.10.4, starting on page 73. 


1.3 ABSTRACT SYNTAX 


In every interpreter in this book, programs are represented as abstract-syntax trees 
(ASTs). And as noted in Section 1.1, abstract syntax isn’t just a great representation; 
abstract-syntax trees are the best way to think about syntax. Alas, in C, AST repre- 
sentations are a pain to code. To ease the pain, the representations in this book are 
generated from a little language that is used only to describe abstract-syntax trees. 
This language also helps with our thinking. As an example, the language describes 
the abstract syntax of an Impcore definition like this: 


27d. (simplified example of abstract syntax for Impcore 27d) = 28> 
Def = VAL (Name, Exp) 
| EXP (Exp) 
| DEFINE (Name, Namelist, Exp) 


This description defines Def as a category of abstract-syntax tree, which includes 
only the true definitions; extended definitions are XDefs. Each form of Def isnamed 
(VAL, EXP, or DEFINE), and following the name of the form is acomma-separated list 
showing what values or subtrees each form is made from. 
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The same language is used to specify the abstract representation of an expres- 
sion, which has more forms: 


28. (simplified example of abstract syntax for Impcore 27d) += 127d 
Exp LITERAL (Value) 
VAR (Name) 
SET (Name, Exp) 


| 
| 
| IF (Exp, Exp, Exp) 
| WHILE (Exp, Exp) 

| BEGIN (Explist) 

| APPLY (Name, Explist) 

This description is worth comparing this with the description of expinthe grammar 
for Impcore (Figure 1.1, page 18). 

An abstract-syntax tree for a given form is usually drawn with the form’s name 
at the root and with its subtrees connected to it by solid lines. When a form has 
no subtrees, like LITERAL or VAR, its single node can be drawn with the associated 
Value or Name just underneath. For example, the abstract-syntax tree for the Imp- 


core expression (set i (- (+ (*2j) i) (/ k 3))) can be drawn like this: 


SET 
4 ™N 
i pane 
ae Explist 
= ~ 
APPLY APPLY 
Ss ———~, 
+ Explist / Explist 
7 N\ 7 XN 
pod VAR VAR LITERAL 
vA : 
* Explist2 k 3 


Za “XN 
LITERAL VAR 
2 j 

An abstract-syntax tree is much easier to analyze, manipulate, or interpret than 
source code. And ASTs focus our attention on structure and semantics. Concrete 
syntax becomes a separate concern; one could easily define a version of Impcore 
with C-like concrete syntax, but with identical abstract syntax. 

Abstract syntax is created from concrete input by a parser, which also identifies 
and rejects ill-formed phrases such as (if x 0) or (val y). Parsing is covered in 
a large body of literature; for textbook treatments, try Appel (1998) or Aho et al. 
(2007). A parser for Impcore, which you can easily extend, can be found in Ap- 
pendix G. 


1.4 ENVIRONMENTS AND THE MEANINGS OF NAMES 


An expression like (* x 3) cannot be evaluated by itself; to know its value, we must 
know what x is. Similarly, to know the effect of evaluating an expression like 
(set x 1), we must know whether x is a formal parameter, a global variable, 
or something else entirely. In programming-language theory, knowledge about 
names is kept in an environment, which is usually a mapping from names to mean- 
ings. Environments are often implemented as hash tables or search trees, and in 
an implementation, an environment is sometimes called a symbol table. 

Knowing what can be in an environment tells us what kinds of things a name 
can stand for, which is a good first step in understanding a new programming lan- 
guage. To understand Impcore, we need to know about three environments, each 
of which is written using its own metavariable: 


+ Environment € (xi, pronounced “ksee”) holds values of global variables. 


+ Environment ¢ (phi, pronounced “fee”) holds definitions of functions. 


+ Environment p (rho, pronounced “roe”) holds values of a function’s param- 
eters. 


Environments € and ¢ are global and shared, but there is a distinct p for every func- 
tion call. Together, the contents of the three environments comprise Impcore’s 
basis. 

Aname can be defined in all three environments at once. But it’s a bad idea: 


29. (transcript 12a) += 126c 64> 
-> (val x 2) 
2 
-> (define x (y) (+ x y)) ; pushing the boundaries of knowledge... 
-> (define z (x) (x x)) 7 and sanity 
—-> (z 4) 
6 


The val definition introduces a global variable x, which is bound to value 2 in en- 
vironment €. The first define introduces a function x that adds its argument to 
the global variable x; that function is bound to name x in environment ¢. The sec- 
ond define introduces function z, which passes its formal parameter x to the func- 
tion x; when z is called, parameter x is bound to 4 in environment p. This example 
should push you to understand the rules of Impcore; to follow it, you have to know 
not only that Impcore has three environments but also how the environments are 
used. Of course, no sane person programs this way; production code is written to 
be easy to understand, even by readers who may have forgotten details of the rules. 

Mathematically, an environment is a function with a finite domain, from 
aname to whatever. In Impcore, environments € and p map each defined name toa 
value; ¢ maps each defined name to a function. Whatever a name is mapped to, all 
environments are manipulated using the same notation, which is mostly function 
notation. For example, whatever is associated with name z in the environment p 
is written p(x). The set of names bound in environment pis written dom p. An ex- 
tended environment, p plus a binding of the name < to v, is written p{x +> v}. 
In an extended environment, the new binding hides previous bindings of x, so 
lookup is governed by this equation: 


eters eG | fy, cheap ze 


Finally, an empty environment, which does not bind any names, is written {}. 
One environment can be combined with another, but because combining en- 
vironments is not useful in Impcore, the notation is deferred to Chapter 2. 


1.5 OPERATIONAL SEMANTICS 


Earlier in this chapter, Impcore is defined informally and concisely, if imprecisely 
(Section 1.2). For a precise understanding of what Impcore is, we could consult the 
implementation (Section 1.6), but an implementation is much longer and harder 
to understand than an informal description. An implementation also lacks focus; 
code embodies many irrelevant decisions, including decisions about the represen- 
tations of names, environments, and abstract syntax. Those decisions are part of 
the implementation, not part of the language. 

In this section, Impcore is defined using a technique that is concise, focused, 
and precise: formal operational semantics. Operational semantics specifies behav- 
ior precisely while hiding implementation details. Although the notation can be 
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Table 1.4: Metavariables of Impcore’s operational semantics 


€, €; An expression 

d A definition 

Lv, 2; A name that refers to a variable or a parameter 
f A name that refers to a function 

U, Ui A value 

€,€’,.... A global-variable environment 

¢,¢’,... A function-definition environment 

p,p',... A formal-parameter environment 


intimidating at first, with practice operational semantics becomes as easy to read 
as informal English. 

Impcore’s operational semantics defines an abstract machine and rules for its 
execution. The semantics defines the machine's states, including its start state and 
its acceptable final states, and it presents rules for making transitions from one 
state to another. By applying these rules repeatedly, the machine can go from a 
start state like “I just turned on and have this program to evaluate” to an accepting 
state like “the answer is 42.” 

A machine may reach a state from which it cannot make progress; for example, 
a machine evaluating (/ 1 0) probably cannot make a transition. When a machine 
reaches such a state, we say it “gets stuck” or “goes wrong.” An implementation 
might indicate a run-time error. 

An Impcore machine’s states and transitions are described using the metavari- 
ables from Sections 1.2 and 1.4, which describe syntax, values, and semantics (Ta- 
ble 1.4). The state of an Impcore machine has four parts: a definition d or expres- 
sion e being evaluated; a value environment £, which holds the values of global 
variables; a function-definition environment ¢; and a value environment p, which 
holds the values of formal parameters. Definitions do not appear inside functions, 
so when the machine is evaluating a definition d, there are no formal parameters, 
and its state is written as (d, €, b). When the machine is evaluating an expression e, 
its state is written as (e, €, b, p). When the machine is resting between evaluations, 
it remembers only the values of global variables and the definitions of functions, 
and its state is written as (£, ¢). 

Environments € and p store values, which in Impcore are integers. Environ- 
ment ¢ stores both primitive functions and user-defined functions. A primitive 
function is written as PRIMITIVE(®), where © stands for a name like +, =, or x. 
A user-defined function is written as USER((x1,...,n),€), where the 2;’s are the 
formal parameters and e is the body. 

In the initial state of the Impcore machine, € = {}, because there are no global 
variables defined. But ¢ = ¢o, where ¢o is preloaded with the definitions of prim- 
itive functions as well as the user-defined functions in the initial basis (Figure 1.3 
on page 27). 


1.5.1 Judgments and rules of inference 


State transitions are described using judgments, which take one form for defini- 
tions and another form for expressions. The judgment for the evaluation of an 
expression, (e,£,,p) | (v,€',¢, p’), means “evaluating expression e produces 
value v.” More precisely, it means “in environments €, ¢, and p, evaluating e pro- 
duces a value v, and it also produces new environments €’ and p’, while leaving ¢ 


unchanged.” This judgment uses eight metavariables; e stands for an expression, 
€, ¢, and p stand for environments, and v stands for a value. Different metavaria- 
bles are distinguished by giving them subscripts, or as with the environments, by 
using primes. 

The form of the judgment (e, €, 4, p) |) (v, €’, d, p’) tells us a few things: 


+ Evaluating an expression always produces a value, unless of course the ma- 
chine gets stuck. Even expressions like SET and WHILE, which are typically 
evaluated only for side effects, produce values.? 


+ Evaluating an expression might change the value of a global variable (from €) 
or a formal parameter (from p). 


+ Evaluating an expression never adds or changes a function definition (be- 
cause ¢ is unchanged). 


The form of the judgment doesn’t tell us whether evaluating an expression can in- 
troduce a new variable. (It can’t, but we can be certain of this only if we study the 
full semantics and write an inductive proof, which is Exercise 24 on page 83.) 

The form of the evaluation judgment also gives this semantics part of its name: 
no matter how much computation is required to get from e to v, the judgment 
(e,€,, p) 1) (uv, €’, ¢, p’) encompasses all that computation in one big step. It is 
therefore called a big-step judgment and is part of a big-step semantics. 

The judgment for a definition is simpler; (d, £,¢) — (€’, ¢') means “evaluating 
definition d in the environments € and ¢ yields new environments €’ and ¢’.” The 
different arrow helps distinguish this judgment from an expression judgment. 

Not all judgments describe real program behaviors. For example, unless some 
joker changes the binding of the name + in ¢, ((+ 11), €, ¢, p) 4 (4,6, d, p) doesn't 
describe how Impcore code behaves. To say which judgments describe real behav- 
iors, an operational semantics uses rules of inference. Each rule has the form 


premises 
i (NAME OF RULE) 
conclusion 


If all the premises hold, so does the conclusion. 
For example, the rule 


(e1, € ¢, p) 1 (v1, €, d, p’) UL #0 (e2,€', ¢, p’) 4 (v2, €", b, p”) 
(IF(e1, €2; €3), g, d, p) a (v2, al Q, p”’) 


d 


(IFTRUE) 
which is part of the semantics of Impcore, says that whenever (1, €, @, p) evaluates 
to some nonzero value vj, the expression IF(e€1, €2,€3) evaluates to the result of 
evaluating e2. Because €2 is evaluated in the environment produced by evaluation 
of €1, if e, contains side effects, such as assigning to a variable, the results of those 
side effects are visible to eg. Expression €3 is not mentioned, because when v, + 0, 
e3 is never evaluated. 


2A judgment describes a relation, not a function. In principle, it is possible to have two different 
values v1 # vz such that (e,£, 4, p) (v1, €, d, p’) andalso (e, €, 6, p) I (v2, €’, 6, p’). Alanguage 
that permits such ambiguity is nondeterministic. All the languages in this book are deterministic, but 
multithreaded languages like Java or C# can be nondeterministic. Programs written in such languages 
can produce different answers on different runs. Languages that do not specify the order in which 
expressions are evaluated, like C, can also be nondeterministic. Programs written in such languages 
can produce different answers when translated with different compilers. (See also Exercise 27, page 84.) 

3This property distinguishes an expression-oriented language like Impcore (or ML, Scheme, or 
Smalltalk) from a statement-oriented language like C. Both have imperative constructs that are eval- 
uated only for side effects, but only in C do these constructs produce no values. 
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The rule specifies that e, is evaluated before e2. How do we know? By looking at 
which environments go where. The side effects of e; are captured in environments 
€' and p’, and these are the environments used to evaluate e2. Order of evaluation 
is determined not by the order in which the premises are written, but by the flow of 
data (in this case, the environments) through the computation. That said, the rule’s 
premises are written in the same order as the evaluations they describe. Any other 
order would be, shall we say, discourteous. 

The rules of Impcore’s semantics belong to a larger family of reasoning tech- 
niques called natural deduction. This family gives Impcore’s semantics the rest of 
its name: it is a big-step, natural-deduction semantics. 

Rules of inference can be translated into code. A complete example is done for 
you in Section 1.6: Impcore’s expression-evaluation judgment is implemented by 
function eval. Calling eval(e, €, ¢, p) returns v and has side effects on € and p with 
the result that (€, frefore, ; Poefore) I) (U, Eafter, P; Pafter)» Function eval looks at 
the form of e and considers rules that have e’s of that form in their conclusions. 
It then looks at premises; each evaluation judgment in a premise is implemented 
by a recursive call. For example, to evaluate an IF expression, eval first makes a 
recursive call to itself to find v1, €’, and p’ such that (e1,€,¢, p) |) (v1, &', 9, 0’). 
Then if v; 4 0, eval makes another recursive call to find v2, €”, and p” such that 
(e2,&',, p") tL (v2, €”", ¢, p”). Having satisfied all the premises of rule IFTRUE, 
it then returns vj and the modified environments. 

The rules for every possible form of expression (and definition) are presented 
in the rest of this section. 


1.5.2 Literal values 


A literal value evaluates to itself, without changing any environments: 


. (LITERAL) 


(LITERAL(v), €,@, p) 4 (v,€, 6, 0) 


This rule has no premises, so at a LITERAL node, the recursive implementation of 
eval terminates. 


1.5.3 Variables 


If a name is bound in the parameter or global environment, then evaluating the 
variable with that name produces the value associated with it in the environment. 
Otherwise, no rules apply, the machine gets stuck, and the computation does not 
continue. 

Parameters hide global variables. Name x is a parameter if x € dom p, where 
dom p is the domain of 9, i.e., the set of names bound by p. 


econ (FORMALVAR) 
(vaR(x),€,, p) 4 (p(x), €, % p) 
x¢domp «x€domé (rsa 


(vaR(x),€, 6, 0) 4 (E(x), &, 6, o) 


These rules have premises that involve only membership tests on environments, 
not other evaluation judgments, so at a VAR node, the recursive implementation of 
eval terminates. 


Notation can imply “may differ” or “must equal” but not “must differ” 


When we specify evaluation using a judgment form, we are using a form of 
mathematical logic, which uses primes and subscripts in ways that can be hard 
to learn. When primes or subscripts differ, the metavariables they decorate may 
or may not differ, like the € and €’ in these examples: 


* The general form of judgment (e,&,,p) \) (v,&', 9d, p’) 
The general form uses € on the left and €’ on the right. Environments 
€ and €' look different, but the notation means only that they may differ. 
The form says, “evaluating an unknown expression e may change a global 
variable.” What actually happens depends on what rules you use and what 
judgment you prove. 


Conclusion of LITERAL (LITERAL(v), &, 4, p) 1) (v, €, 9, p) 

The LITERAL rule proves a judgment that uses € on both the left and the 
right. Because € must equal €, the judgment says, “evaluating a literal ex- 
pression LITERAL(v) does not change or add a global variable.” 


Conclusion of GLOBALASSIGN (SET(x,e),€,¢,p) |) (v,é'{a + v}, ¢, p’) 


Environments € and €'{x +> v} look like they must differ. But it’s not so: 
€ may equal €’, and €’ may map «to v. In that case, € and é'{x +> v} are 
equal. Imagine evaluating (set x 0) when x is already zero. 


Our notation can imply only that two environments “may differ” or “must equal” 
each other. For example, in the rule for IFTRUE on page 34, € may equal £’, 
which may equal €”, as in (if (>n 0) n (- @n)). Or € may equal €’, but they 
may both differ from €”, asin (if (>n@) (set sign 1) (set sign-1)). 


What if € and £’ must differ? That can’t be said with primes or subscripts; primes 
and subscripts can say only “may differ” or “must equal.” To say that two things 
must differ, write an explicit premise, like “v, 4 0” or “€ # &/.” 


The notation is most important when you write your own derivations. Begin- 
ners often write primes or subscripts as they appear in rules. But a prime or 
subscript says “I don’t know; it may differ,” and in a derivation, this is almost 
always wrong—we do know. Here’s an invalid derivation, intended to describe 
the evaluation of (if (> @) n (- 0n)) when n is 7 (I’ve taken a minor liberty 
with the notation): 


(20), E08 ¢,0) 1A0 (np) (7800). 
(IF((> n 0),n, (- 0 n)),& 9, p) al Te" sop) 


The conclusion is bogus. Because €’’ appears only in the conclusion, there is 
nothing that €” must equal, and that means the judgment says, “evaluating the 
if expression produces 7, and afterward, global variables have arbitrary values.” 
(The same goes for p’’.) To avoid this problem, remember that in any judgment 
that you prove, the elements of the final state must equal something that you 
specify. Do that and you'll write good derivations. 
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1.5.4 Assignment 


Evaluating an assignment changes the value of a variable, and it produces the value 
of the right-hand side. Assignment, like variable lookup, prioritizes parameters: 
if the name x is bound in the parameter environment p, its binding is changed 
there; otherwise, x had better be bound in the global environment €. 


xré€domp  (e,£,¢,p) 1 (v,€',¢,p') 
(SET(x, €), €,, 0) I (uv, €', ¢, p' {x + v}) 


(FORMALASSIGN) 


x ¢ dom p x € dom€ (e,€, 0, p) 4 (uv, €',¢, 0’) 
(sET(a,€),€,,p) } (v, 6’ {a +> v}, 6, p') 


Each of these rules has a premise that shows an evaluation of the right-hand side e, 
so at a SET node, the recursive implementation of eval always makes a recursive 
call. And even though there are two rules with SET in the conclusion, only one can 
apply at one time, because the premises 1 € dompand a ¢ dom pare mutually 
exclusive. This property enables the implementation to know exactly what to do 
with a SET node, and it keeps the evaluation of Impcore programs deterministic. 

Because of the premises x € domp and x € dom, only a previously defined 
variable may be assigned to; given a SET node where x ¢ dompand xz ¢ domé, 
the machine gets stuck. In many languages, like Awk for example, assignment to an 
undefined and undeclared variable creates a new global variable (Aho, Kernighan, 
and Weinberger 1988), as specified by the following rule: 


x ¢ dom p (65,6, p) ¥ (E50) 
(sET(x,€),£,9,p) } (uv, €/{x + v}, d, p’) 


In Impcore, a new global variable can be created only by a VAL definition, as shown 
below in rule DEFINEGLOBAL (page 37). To spot such subtleties, you have to read 
inference rules carefully. 


(GLOBALASSIGN) 


(GLOBALASSIGN for Awk) 


1.5.5 Control flow 
Conditional evaluation 


The expression IF(€1, €2, €3) first evaluates the expression e; to produce value 1. 
If v; is nonzero, the IF expression produces the result of evaluating e2; otherwise, 
it produces the result of evaluating e3. Each case is described by its own rule. 


(e1,€, d, p) 4 (v1, €', >, p’) U1 a 0 (e2,€',¢, p') 1 (v2, €",b, p”") 
(IF(e1, €2, €3), g ¢, p) a (v2, ae d, p’’) 


(IFTRUE) 


(e1, €, d, p) ay (v1, &', d, p’) Uae 0 (e3,€',¢, p') ay (u3,E", b, p"') 
(IF(€1, €2, €3), g ¢, p) 1 (v3, Ell, d, i) 


(IFFALSE) 
Like the two rules for SET, these rules have mutually exclusive premises (v; 4 0 
and v, = 0). Evaluation is deterministic, and by examining v1, the implementation 
knows which rule to apply. 


Loops 


A WHILE loop first evaluates the condition e; to produce value v1. If v, is nonzero, 
evaluation continues with the body e2, and then the WHILE loop is evaluated again. 


(e1,€, d, p) a (v1, €, d, p’) U1 #0 
(e2, gs d, p’) V (v2, Eu, ¢, p’) (WHILE(€1, e2), Gs d, p") V (v3, ae d, pl") 
(WHILE(€1, €2), g, d, p) a (v3, ge; ¢, pl") 


(WHILEITERATE) 
In this rule, the value v2, which is produced by evaluating the body e€g, is thrown 
away. We can tell by looking at the final state of the judgment in the conclusion 
of the rule. That state has elements v3, €’”, 6, and p’”, and if you study the rule 
carefully, you'll see that none of these elements depends on or uses v2. A WHILE 
loop evaluates its body e2 only for its side effects, i.e., for the new environments 
&" and p”. They are then used to make the final environments é’” and p’”. 
If the condition in a WHILE loop evaluates to zero, the loop terminates, and the 
loop also evaluates to zero. 


(e1,€, >, p) ay (v1, €', ¢, p’) V1 =0 
(WHILE(€1, €2), g, ¢, p) 1 (0, ise ¢, p’) 
If the evaluation of a WHILE loop terminates, it always produces zero, even when 


rule WHILEITERATE is used (Exercise 23 on page 83). A WHILE loop is therefore 
executed for its side effects. 


(WHILEEND) 


Sequential execution 


A nonempty BEGIN evaluates its subexpressions left to right, producing the result 
of the final expression ey. 


(e1, 0,9, Po) a (v1, 61, , pr) 
(€2, 61, ¢, Pi) al (v2, €2, , p2) 
(ena als ¢, Pn—1) al (ns Ens d, Pn) 
(BEGIN(€1, CQ, +055 Cn); £0; Q, Po) a (Un; G5 d, Pn) 


(BEGIN) 


Values v, to vj_ 1 are ignored, but the environments €; and p1, which result from 
evaluating e1, are used to evaluate e2, andso on. The use of € and p to evaluate e2 
implies that e, is evaluated before e2. Order of evaluation is determined by this 
“threading” of environments, not by the order in which the premises are written. 
For example, the BEGIN rule might equally well have been written this way: 


(Cn; Ents d, Pry a (ras Ens ¢, Pn) 
(Cn—1, En—-2; d, Pn—2) al (Un—1; fais d, Pn—1) 


(€1, £0, ?; po) ay (v1,€1, 9, pr) . 
(BEGIN(€1, €Q,++-, Cn), £0; ¢, Po) al (Un; ba; d, Pn) 


(equivalent BEGIN) 


This equivalent rule still specifies that e; is evaluated before e2, andso on, but when 
the rule is written this way, it is not as easy to understand. 
A BEGIN might be empty, in which case it evaluates to zero. 


(EMPTYBEGIN) 


(BEGIN(),€,¢, p) 4) (0, €, , p) 
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1.5.6 Function application 


In the rules for function application, operational semantics first starts to show its 
advantages: the description is precise, and it is much more concise than an imple- 
mentation. 


User-defined functions 


Application of a user-defined function f evaluates argument expressions €, to €,, 
then evaluates the body of f in a new environment that binds each formal param- 
eter to the value of the corresponding argument. 


o(f) = USER((21, ges ,2n); e) 
%1,...,%y all distinct 


(e1, &0; ¢, Po) a (v1, 1, @, p1) 


(ris En—15 ¢, Pn—1) al (Un, ony d, Pn) 
GS d, {£1 > U1, +++,0n > Un }) 4 (une! s Q, p’) 
(APPLY(f, El,-++, Cas C0s ¢, po) a (v, EG d, Pn) 


Asin the BEGIN rule, expressions €; through e,, are evaluated in order. Their values 
Vv, to Up, are used to create a new, unnamed formal-parameter environment that 
maps each formal parameter x; to the corresponding v;. This environment is used 
as a p to evaluate e, the body of the function. 

The rule has these implications: 


(APPLYUSER) 


* The behavior of a function doesn’t depend on the function's name, but only 
on the definition to which the name is bound. 


* The body of a function can’t get at the formal parameters of its caller, since 
the body e is evaluated in a state that does not contain ~o,..., Pn. 


« If a function assigns to its own formal parameters, its caller can’t get at the 
new values, because the caller has no access to the environment p’. 


After the body of a function is evaluated, the environment p’ containing the 
values of its formal parameters is thrown away. This fact matters to imple- 
mentors of programming languages, who can use temporary space (in reg- 
isters and on the stack) to implement formal-parameter environments. 


In short, the formal parameters of a function are private to that function—neither 
its caller nor its callees can see them or modify them. The privacy of formal param- 
eters is an essential part of what language designers call “functional abstraction,” 
which both programmers and implementors rely on. 


Primitive functions 


Application of a primitive function resembles the application of a user-defined 
function. The arguments are evaluated, and the application produces the result 
of performing a primitive operation on their values. In principle, each primitive is 
describe by its own rule or rules, but this book shows only a few representatives. 


The arithmetic primitives are represented by addition: 


o(f) = PRIMITIVE(+) 


(€1, £0, 9; Po) al (v1, €1, ; P1) 
(e2, 41,4, p1) 1 (v2, €2,¢, p2) 
— 231 <u, tue < 231 
(APPLY(f, €1, €2), £0, 9, Po) al (vy + v2, €2, 9, p2) 


The final condition on the sum v; + v2 ensures that the result can be represented 
in a 32-bit signed integer. 

Comparison primitives are represented by equality. Like the if expression, 
the equality primitive is specified by a pair of rules which have mutually exclusive 
premises (vj = vg and v, # v2): 


. (APPLYADD) 


o(f) = PRIMITIVE(=) 


(e1, £0, 9; Po) al (v1, 1, d, Pi) 
(€2, €1, Q, P1) a (v2, €2, &, p2) 


U1 = V2 


(APPLY(f, el, €2), £0; d, Po) al (1, 2, Q, pee (APETYEOTEUE) 
o(f) = PRIMITIVE(=) 
(e1, £0; d, Po) a (v1, &1, ¢, P1) 
(e2, &1, d, Pi) al (v2, &9, d, p2) 
MF ve . (APPLYEQFALSE) 


(APPLY(f, €1, e2), £0; d, po) a (0, &2, é, p2) 


The printing primitives are represented by print1n. These primitives have an 
important behavior that can’t be expressed by our formal evaluation judgment: 
they print. Because this behavior is omitted, the rule makes print1n look like the 
identity function. 


o(f) = PRIMITIVE(print1n) 


fee, d, p) ay (u.e", @, p’) 


The printing primitives could be modeled formally without much trouble; 
for example, we could extend the abstract-machine state to include a sequence of 
all characters ever printed. I prefer, however, not to clutter our semantics with 
such a list. Leaving the specification of printing informal is OK because our se- 
mantics is intended to convey understanding, not to nail down every last detail. 


(APPLYPRINTLN) 


1.5.7 Rules for evaluating definitions 


The rules above specify the effects of evaluating expressions. The effects of eval- 
uating definitions are different: evaluating a definition does not produce a value, 
but unlike an expression, it may introduce a new global variable or a new function. 
New variables are added to € and new functions are added to @, so the evaluation 
of a definition is described by a judgment of the form (d, €,¢) — (&', ¢’). Below, 
this judgment is used in rules for true definitions, which are implemented by the 
evaldef function in Section 1.6.2. Extended definitions aren’t formalized. 


Variable definition 


The definition VAL(«, e) introduces a global variable x. It adds the binding 1 4 v 
to the global environment €’, where v is the result of evaluating e. A definition does 
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not appear in the body of a function, so e is evaluated without any formal parame- 
ters (pis {}). The DEFINEGLOBAL rule closely resembles the GLOBALASSIGN rule, 
but the DEFINEGLOBAL rule does not require x € dom €. It is OK if x is already a 
global variable, in which case VAL(, e) behaves just like SET(~, e). 


(6,6 Oh) 4 (6, b,0") 


(DEFINEGLOBAL) 
(vAL(a,€),€,) — (g’{x +> v}, 6) 
Function definition 
The definition DEFINE(f, (11,...,%n),e) introduces a function f. The function 
is represented as USER((21,...,2n),e), where %1,...,», are the names of the 


formal parameters and € is the body. No two parameters may have the same name. 


L1,..-,%y all distinct 


(DEFINE(f, (@1,---,2n),€),§, 0) > (€, {ff  USER((21,...,2n),e)}) 


(DEFINEFUNCTION) 


Top-level expression 


An expression e, when entered at the read-eval-print loop, also serves as a defini- 
tion. This “definition” does not introduce any new names into € or ¢; e€ is evaluated 
for its side effect, and its value is stored in the global variable it. Therefore, eval- 
uating an expression as a definition can modify the global-variable environment & 
but not the function environment ¢. 


(6,6 @ th) 4 (7,65 6,0) 
(ExP(e),£,) — (é'{it > v}, ) 


Evaluating the “definition” EXP(e) has exactly the same effects as evaluating the 
more conventional definition VAL (it, e). 


(EVALEXP) 


Extended definitions 


As mentioned in the sidebar on page 24, Impcore’s extended-definition forms use, 
check-expect, check-assert, and check-error aren't specified formally. Evalu- 
ating use evaluates the definitions contained in the file named by the use, then 
runs that file’s unit tests. And evaluating a check-expect, a check-assert, or 
a check-error remembers a unit test. Specifying use formally would require a 
model of files with names and contents. Specifying unit tests would require adding 
a set of pending unit tests to our abstract machine, plus judgments and inference 
rules that would describe what it means for a test to succeed or fail. Such things 
would distract us from what the semantics is meant to do: help us understand and 
compare programming languages. 

To understand these issues for yourself, try designing rules for extended def- 
initions. Start by defining the success or failure of check-expect (Exercise 17) or 
the success of check-error (Exercise 21). To specify check-error, you will need to 
design a proof system that says what it means for evaluation to halt with an error. 


1.6 THE INTERPRETER 


A bridge language like Impcore is meant to be small enough to learn, small enough 
to specify, small enough to implement, and yet big enough to write interesting pro- 
grams in. (Or in the case of Impcore, not quite big enough.) To write programs 


requires an implementation, but why talk about it? Why not bury the implementa- 
tion in a repository somewhere? Because the implementation of an interpreter can 
illustrate a language and its semantics in a way that nothing else can. And when you 
want to experiment with alternative language designs, you can build on or change 
my code. To make such experiments possible, I can’t just hand you the code; I have 
to explain it. But I can’t explain all of it—the explanations would add over 300 pages 
to this book. In this chapter, I explain just the most important parts. 

A language is embodied by the data structures for its crucial abstractions (envi- 
ronments and abstract-syntax trees) and by the functions that evaluate expressions 
and definitions. They are all explained in this chapter. The crucial code is built on 
top of infrastructure: error handling, parsing, printing, test reporting, and so on. 
That infrastructure is lovingly described in a Supplement to this book, which is 
available from build-prove-compare.net. The interpreter requires only a stan- 
dard C library, and with that and the Supplement, you can understand as much or 
as little as you wish. 

The code is presented using the Noweb system for literate programming. Noweb 
extracts code directly from the text, so the code in the book is the code that runs. 
Noweb splits code into named “code chunks,” which are surrounded by textual ex- 
planations. The code chunks are written in an order designed to support good ex- 
planations, not the order dictated by a C compiler. 

Code chunks can mix source code with references to other chunks. References 
are italicized in angle brackets, as in (evaluate e->ifx and return the result 49c). 
The label “49c” shows where to find the definition: the number identifies a page, 
and when the page contains more than one chunk, each chunk gets its own lower- 
case letter, which is appended to the page number. The label also appears on the 
first line of the definition, in bold. Each chunk definition is shown using the = sign. 
A definition can be continued in a later chunk; Noweb concatenates the contents of 
all definitions of the same chunk. A definition that continues a previous definition 
is showing using the += sign in place of the = sign. When a chunk’s definition is 
continued, the right margin displays pointers to the previous and next definitions, 
written “<a 48a” and “s296ap.” The notation “(48b)” shows where a chunk is used. 

To help you find relevant chunks, Noweb provides a mini-index in the margin of 
each right-hand page. For example, the mini-index on page 49 reveals that function 
bindval is defined in chunk 45b on page 45. It also reveals that type Exp is not 
defined by hand-written code; it is generated automatically. In any mini-index, 
A stands for automatically generated code, and 6 stands for a basis function from 
C’s standard library. And P, which is used from Chapter 2 onward, stands for a 
primitive function that is defined in an interpreter. 

In most chapters, Noweb’s information is supplemented by a table that relates 
semantics, concepts, and code, like Table 1.5 on the next page. This table will help 
you learn the important parts of the code, which all relate to metavariables and 
math symbols from Section 1.5. 

The code will be clearer to you if you know my programming conventions. For 
example, when I introduce a new type, I use typedef to give it a name that begins 
with a capital letter, like Name, or Exp, or Def. The representation of such a type is 
often exposed, in which case you get to see all of the type’s definition, and you get 
access to fields of structures and so on. A type whose representation is exposed is 
called manifest; for example, types Exp and Def are manifest. A type might also be 
abstract, in which case you can’t get at its representation. In C, an abstract type is 
always a pointer to a named struct whose fields are not specified. For example, 
type Name is abstract; you can store a Name in a field or a variable, and you can pass 
a Name to a function, but you can't look inside a Name to see how it is represented. 
(Strictly speaking, you can see everything; as explained in Chapter 9, it is your client 
code, and mine, that cannot see the representations of abstract types.) 
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Table 1.5: Correspondence between Impcore semantics and code 


Semantics Concept Interpreter 
d True definition Def (page 42) 
e€ Expression Exp (page 42) 
Ce f Name Name (page 43) 
v Value Value (page 43) 
An imperative core USER(--- ) Function Userfun (page 42), Func (page 44) 
PRIMITIVE(@) Function Name (page 43), Func (page 44) 
40 £,0 Value environment Valenv (page 44) 
0) Function environment Funenv (page 44) 
(e, €,, p) Expression evaluation eval(e, €, ¢, p) =v, with 
(uv, &', >, p’) € and p updated to €’ and p’ 


(page 48) 

evaldef(e, £, d, echo) 
updates € to €’ and ¢ to ¢’ 
(page 53) 


Definition evaluation 


(d,£,) > (6, p’) 


x € dom p Definedness isvalbound (page 45) 
f €dom¢ Definedness isfunbound (page 45) 
p(x), E(x) Lookup fetchval (page 44) 
o(f) Lookup fetchfun (page 44) 
p{z > v} Binding bindval (page 45) 
OL fr---} Binding bindfun (page 45) 


I write the names of functions using lowercase letters only, except for some 
automatically generated functions used to build lists. 

To the degree that C permits, I distinguish interfaces from implementations. 
An interface typically includes some or all of these elements: 


* Types, which may be manifest or abstract 
* Invariants of manifest types, if any 
* Prototypes of functions 


+ Documentation explaining how the types and functions should be used 


An atypical interface might also include declarations of global variables, macros, 
or other arcana. But no interface, typical or atypical, ever includes the implemen- 
tations of its functions. 

Interface documentation explains not only how to use functions but also what 
happens when a function is used incorrectly; in particular, it explains who is re- 
sponsible for detecting or avoiding an error. A checked run-time error is a mistake 
that the implementation guarantees to detect; a typical example would be passing 
a NULL pointer to a function. The implementation need not recover from a checked 
error, and indeed, many of my implementations simply halt with assertion failures. 

An unchecked run-time error is more insidious; this is a mistake that it is up to 
the C programmer to avoid. If client code causes an unchecked run-time error, the 
implementation provides no guarantees; anything can happen. Unchecked run- 
time errors are part of the price we pay for programming in C. 

Once you've read and understood an interface, you should be able to use its 
functions without needing to look at their implementations. But of course the cru- 


Run-time errors and safety 


A language in which all errors are checked is called safe. Safety is usually imple- 
mented by a combination of compile-time and run-time checking. Popular safe 
languages include Awk, C#, Haskell, Go, Java, JavaScript, Lua, ML, Perl, Python, 
Ruby, Rust, Scheme, and Smalltalk. A safe language might be characterized by 
saying that “there are no unexplained core dumps”; a program that halts always 
issues an informative error message. 


A language that permits unchecked errors is called unsafe. Unsafe languages 
put an extra burden on the programmer, but they provide extra expressive 
power. This extra power is needed to write things like garbage collectors and 
device drivers; systems programming languages, like Bliss and C, have histor- 
ically been unsafe. C++ is an anomaly: it is ostensibly intended for high-level 
problem-solving, but it is nevertheless unsafe. 


A few well-designed systems-programming languages are safe by default, 
but have unsafe features that can be turned on explicitly at need, usually by 
a keyword UNSAFE. The best known of these may be Cedar and Modula-3. 


cial implementations, of functions like eval and evaldef, are intended for you to 
look at. When you look at them, you'll see that they respect these conventions: 


* Within reason, each local variable is declared in the region in which it is used; 
local variables typically don’t scope over an entire function definition. 


* When possible, each variable is initialized where it is declared, making its 
declaration resemble a val definition in Impcore. 


On to the code! The presentation begins with the interfaces in Section 1.6.1. 
These interfaces include not only the interfaces associated with the evaluator, but 
also some interfaces associated with general-purpose utility code from the Supple- 
ment (Appendix F). These interfaces are necessary building blocks, but they aren't 
the main event; the main event is the implementation of Impcore’s operational se- 
mantics in Section 1.6.2, which starts on page 48. 


1.6.1 Interfaces 


Everything comes together in the evaluator, which implements the operational se- 
mantics. That evaluator is supported by interfaces for the central structures of a 
programming language: syntax, names, values, environments, and lists thereof. 
It is also supported by interfaces used for printing and for reporting errors. 


Interface to abstract syntax: Manifest types and creator functions 


The abstract-syntax interface exposes the representations of definitions, expres- 
sions, and so on. It also provides convenient creator functions which are used to 
build abstract-syntax trees. 

An abstract-syntax tree is a value of a sum type; such a type is also called a 
discriminated-union type. A sum type specifies a list of alternative forms; every value 
of the type takes the form of one of the alternatives. Sum types play an essential role 
in symbolic computing, but they are not directly supported in C. C provides only an 
undiscriminated union, sometimes also called an “unsafe” union. A C union spec- 
ifies a list of alternative forms, called “members,” but from the union alone, you 
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can’t tell what form a value or variable is intended to have. To represent a sum type 
in C requires not only a union but also a discriminant (a “tag”), which says which 
form of the union is in use. In this book, the tag and the union are placed together 
inaCstruct. The tag is called alt (for “alternative”), and the union is unnamed. 
A tag is referred to by name, as in e->alt, and in the union, each alternative is re- 
ferred to by name, as in e->var or d->define. An alternative may itself have mul- 
tiple named parts; for example, if d represents a val definition, the name of the 
variable being defined is d->val.name, and the expression that gives it its initial 
value is d->val.exp. 

The name of each alternative appears in two places: in an enumeration type 
that defines the possible values of alt, and in the union type, which lists the possi- 
ble forms of the union. And in keeping with common C practice, each enumeration 
literal is written using all capital letters, and each member of the union is written 
in lower case. 

Our first complete example is the true definition Def, a simplified version of 
which appears in chunk (simplified example of abstract syntax for Impcore 27d). A Def 
is a sum type with three alternatives, called VAL, EXP, and DEFINE. 
42a. (type and structure definitions for Impcore 42a)= 44c> 

typedef struct Userfun Userfun; 
struct Userfun { Namelist formals; Exp body; 3; 


typedef struct Def *Def; 
typedef enum { VAL, EXP, DEFINE 3 Defalt; 
struct Def { 

Defalt alt; 


union { 

struct ¢ Name name; Exp exp; 3 val; 

Exp exp; 

struct ¢ Name name; Userfun userfun; 3 define; 
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3; 

Such type definitions and creator functions are hard to write and maintain by 
hand. So I generate them automatically, using an ML program that appears in Ap- 
pendix J. That program generates the Def type and associated functions from the 
following descriptions: 
42b. (definition.t 42b)= 

Userfun = (Namelist formals, Exp body) 


Def* = VAL (Name name, Exp exp) 
| EXP (Exp) 
| DEFINE (Name name, Userfun userfun) 


A valid Userfun satisfies the invariant that the names in formals are all distinct. 
The abstract syntax for Exp, which you might wish to compare with the concrete 
syntax given for exp on page 18, is described as follows: 


42c. (exp.t 42c)= 


Exp* LITERAL (Value) 
VAR (Name) 
SET (Name name, Exp exp) 


WHILEX (Exp cond, Exp exp) 
BEGIN (Explist) 


| 
| 
| IFX (Exp cond, Exp truex, Exp falsex) 
| 
| 
| APPLY (Name name, Explist actuals) 


The descriptions above’ are slightly elaborated versions of (simplified example 
of abstract syntax for Impcore 27d). Similar descriptions are used for much of the 
C code in this book. 

True definitions and expressions are the essential elements of abstract syntax; 
once you understand how they work, you will be ready to connect the operational 
semantics and the code. Impcore’s extended definitions, including unit tests, are 
described in the Supplement. 


Interface to names: An abstract type 


Programs are full of names. To make it easy to compare names and look them up 
in tables, I define an abstract type to represent them. Although each name is built 
from a string, the abstract type hides the string and its characters. Unlike C strings, 
names are immutable, and two names are equal if and only if they are the same 
pointer. 
43a. (shared type definitions 43a)= (S295a) 
typedef struct Name *Name; 
typedef struct Namelist *Namelist; // list of Name 


Aname may be built from a string or converted to a string. 


43b. (shared function prototypes 43b)= (S295a) 46b> 
Name strtoname(const char *s); 
const char *nametostr(Name x); 


These functions satisfy the following algebraic laws: 


stremp(s, nametostr(strtoname(s))) == 
stremp(s, t) == Oif and only if strtoname(s) == strtoname(t) 


The first law says if you build a name from a string, nametostr returns a copy of 
your original string. The second law says you can compare names using pointer 
equality. 

Because nametostr returns a string of type const char*, a client of nametostr 
cannot modify that string without subverting the type system. Modification of the 
string is an unchecked run-time error. New values of type Name* should be created 
only by calling strtoname; to do so by casting other pointers is a subversion of the 
type system and an unchecked run-time error. 


Interface to values 


The value interface defines the type of value that an expression may evaluate to. 
In Impcore, that is always a 32-bit integer. A Valuelist is a list of Values. 
43c. (type definitions for Impcore 43c)= (S295a) 44a> 


typedef int32_t Value; 
typedef struct Valuelist *Valuelist; // list of Value 


‘The alternatives for if and while are named IFX and WHILEX, not IF and WHILE. Why? Because 
corresponding to each alternative, there is a field of a union that uses the same name in lower case. 
For example, if e isa LITERAL expression, the literal Value is found in field e->literal. But a structure 
field can’t be named if or while, because the names if and while are reserved words—they may be used 
only to mark C syntax. So I call these alternatives IFX and WHILEX, which I encourage you to think of 
as “if-expression” and “while-expression.” For similar reasons, the two branches of the IFX are called 
truex and falsex, not true and false. And in Chapter 2, you'll see LETX and LAMBDAX instead of LET 
and LAMBDA, so that I can write an interpreter for jzScheme in Scheme. 
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Interface to functions, both user-defined and primitive 


In the Impcore interpreter, the type “function” is another sum type. This type 

specifies two alternatives: user-defined functions and primitive functions. Fol- 

lowing the operational semantics, which represents a user-defined function as 

USER((21,...,2@n), ), a user-defined function is represented as a pair containing 

formals and body. A primitive is represented by its name. 

44a. (type definitions for Impcore 43c) += (S295a) <143c 44e> 
typedef struct Funclist *Funclist; // list of Func 


44b. (fun.t 44b)= 
Func = USERDEF (Userfun) 
| PRIMITIVE (Name) 


This description is used to generate these type and structure definitions: 

44c. (type and structure definitions for Impcore 42a) += <142a 
typedef struct Func Func; 
typedef enum { USERDEF, PRIMITIVE 3 Funcalt; 
struct Func { Funcalt alt; union ¢ Userfun userdef; Name primitive; 3 ; 3; 


Also generated automatically are these prototypes for creator functions. 


44d. (function prototypes for Impcore 44d) = (S295a) 44f> 
Func mkUserdef(Userfun userdef); 
Func mkPrimitive(Name primitive); 


Interface to environments: More abstract types 


In the operational semantics, the environments p and € hold values, and the envi- 
ronment ¢ holds functions. Each kind of environment has its own representation.° 
44e. (type definitions for Impcore 43c) += (S295a) <44a 
typedef struct Valenv *Valenv; 
typedef struct Funenv *Funenv; 


Anew environment may be created by passing a list of names and a list of asso- 
ciated values or function definitions to mkValenv or mkFunenv. For example, calling 
mkValenv((11,...,2n), (U1,-.-,Un)) returns {21 4 U1,...,%n +> Un}. Passing 
lists of different lengths is a checked run-time error. 
44f. (function prototypes for Impcore 44d) += (S295a) <44d 44g> 


Valenv mkValenv(Namelist vars, Valuelist vals); 
Funenv mkFunenv(Namelist vars, Funclist defs); 


A value or a function definition is retrieved using fetchval or fetchfun. Inthe 
operational semantics, the lookup fetchval(z, /) is simply p(x). 
44g. (function prototypes for Impcore 44d) += (S295a) <44f 45a> 


Value fetchval(Name name, Valenv env); 
Func fetchfun(Name name, Funenv env); 


5 By defining one C type for environments that hold a Value and another for environments that hold 
a Func, I ensure type safety—but at the cost of having to write two essentially identical versions of each 
function. In C, the only alternative is to define a single C type for environments, which would hold a 
void* pointer, which would then be cast to a Value* or Func* as needed. This choice duplicates no 
code, but it is unsafe; if we accidentally put a Value* in an environment intended to hold a Func*, it is 
an error that neither the C compiler nor the run-time system can detect. In the interests of safety, I du- 
plicate code. Chapter 5 shows how in another implementation language, ML, we can use polymorphism 
to achieve type safety without duplicating code. Similar results can be obtained using C++, Java, and 
other languages. 


If the given name is not bound in the environment, calling fetchval or fetchfun 
is a checked run-time error. To ensure that fetching is safe, first call isvalbound or 
isfunbound; these functions return 1 if the given name is in the environment, and 
0 otherwise. Formally, isvalbound(z, ~) is written x € dom p. 
45a. (function prototypes for Impcore 44d) += (S295a) 344g 45b> 
bool isvalbound(Name name, Valenv env); 
bool isfunbound(Name name, Funenv env); 


To add new bindings to an environment, use bindval and bindfun. Unlike the pre- 
vious six functions, bindval and bindfun are not pure: instead of returning new 
environments, bindval and bindfun mutate their argument environments, replac- 
ing the old bindings with new ones. Calling bindval(z, v, p) is equivalent to per- 
forming the assignment p := p{x +> v}. Because p is a mutable abstraction, mod- 
ifications to the environment are visible to whatever code calls bindval. 
45b. (function prototypes for Impcore 44d) += (S295a) <45a 45¢> 
void bindval(Name name, Value val, Valenv env); 
void bindfun(Name name, Func’ fun, Funenv env); 


These functions can be used to replace existing bindings or to add new ones. 


Interface to the evaluator 


The evaluator works with abstract syntax and values, whose representations are 
exposed, and with names and environments, whose representations are not ex- 
posed. Its interface exports functions eval and evaldef, which evaluate expres- 
sions and true definitions, respectively. (Extended definitions are evaluated by 
function readevalprint, whichis described in the Supplement.) Function eval im- 
plements the |) relation in our operational semantics. For example, eval(e, €, ¢, p) 
findsa v, €’, and p’ such that (e, €, d, p) |) (v, €’, d, p’), assigns p := p’ and€ := €’, 
and returns v. Function evaldef similarly implements the — relation. 
45c. (function prototypes for Impcore 44d) += (S295a) <45b 
Value eval (Exp e, Valenv globals, Funenv functions, Valenv formals); 
void evaldef(Def d, Valenv globals, Funenv functions, Echo echo_level); 


Just as the forms of the evaluation judgments tell us something about the oper- 
ational semantics, the types of the evaluation functions tell us something about 
the implementation. The result types confirm that evaluating an Exp produces a 
value but evaluating a Def does not. Both kinds of evaluations can have side effects 
on environments. Finally, the echo_level parameter, which has no counterpart 
in the semantics, controls printing: when echo_level is ECHOING, evaldef prints 
the values and names of top-level expressions and functions. When echo_level is 
NOT_ECHOING, evaldef does not print. 


Interface to lists 


The evaluator’s data structures include many lists: names, values, functions, ex- 
pressions, and unit tests are all placed in lists. For safety, each list has its own 
type: Namelist, Valuelist, Funclist, Explist, and UnitTestlist. Each of these 
types is recursive; a list is either empty or is a pointer to a pair (hd, t1), where hd is 
the first element of the list and t1 is the rest of the list. An empty list is represented 
by a null pointer. Each list type is defined in the same way, as in this example: 
45d. (example structure definitions for Impcore 45d) = 
struct Explist £ 
Exp hd; 
struct Explist *tl; 
3; 


type 
type 
type 
type 
type 
type 


type 
type 
type 
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The type definitions are generated by a Lua script, which searches header files 
for lines of the form 


typedef struct Foo *Foo; // list of Foo 


For each type of list, the script also generates a length function, an extractor, a cre- 
ator function, and a print function. These functions are named lengthTL, nthTL, 
mkTL, and printTL, where T is the first letter of the list type. The length of the NULL 
list is zero; the length of any other list is the number of its elements. Elements are 
numbered from zero, and asking for nthTL(xs, n) whenn > lengthTL(xs) isa 
checked run-time error. Calling mkTL creates a fresh list with the new element at 
the head; it does not mutate the old list. 

The list functions have prototypes like these: 
46a. (example function prototypes for Impcore 46a) = 

int lengthEL(Explist es); 

Exp nthEL (Explist es, unsigned n); 
Explist mkEL (Exp e, Explist es); 
Explist popEL (Explist es); 

Definitions and function prototypes for all the list types can be found in the in- 
terpreter’s all.h file. Because of the repetition, this code is tedious to read, but 
generating the code automatically makes the tedium bearable. And ML’s polymor- 
phism enables a simpler solution (Chapter 5). 


Interface to infrastructure: Printing 


After evaluating a definition, the interpreter prints a name or a value. And when 
an error occurs, the interpreter may need to print a faulty expression or definition. 
Strings and numbers can easily be printed using printf, but expressions and def- 
initions can’t. So instead, the interpreter uses functions print and fprint, which 
replace printf and fprintf. These functions, which are defined in the Supple- 
ment, support direct printing of Exps, Defs, Names, and so on. 
46b. (shared function prototypes 43b) += (S295a) <43b 47a> 
void print (const char *fmt, ...); // print to standard output 
void fprint(FILE *output, const char *fmt, ...); // print to given file 


By design, print and fprint resemble printf and fprintf: the fmt parame- 
ter is a “format string” that contains “conversion specifications.” Our conversion 
specifications are like those used by printf, but much simpler. A conversion spec- 
ification is two characters: a percent sign followed by a character like d or s, which 
is called a conversion specifier. Unlike standard conversion specifications, ours don’t 
contain minus signs, numbers, or dots. The ones used in the Impcore interpreter 
are shown here in Table 1.6. By convention, lowercase specifiers print individual 
values; uppercase specifiers print lists. Most specifiers are named for the initial let- 
ter of what they print, but the specifier for a Def must not be %d: the %d is too firmly 
established as a specifier for printing decimal integers. Instead, Def is specified 
by %t, for “top level,” which is where a Def appears. 

Functions print and fprint are unsafe; if you pass an argument that is not consis- 
tent with the corresponding conversion specifier, it is an unchecked run-time error. 


Interface to infrastructure: Error handling 


When it encounters a fault, the Impcore interpreter complains and recovers by call- 
ing a function in an error-handling interface. In general, a fault occurs whenever 


Table 1.6: Conversion specifiers for impcore 


oe 
oe 


Print a percent sign 

Print an integer in decimal format 
Print an Exp 

Print a Func 

Print an Explist (list of Exp) 

Print a Name 


oe & & & 
momo a 


oe 
= 


%N Print a Namelist (list of Name) 

%p Print a Par (see Appendix K) 

%P Print a Parlist (list of Par) 

%s Print a char* (string) 

%t Print a Def (t stands for “top level”, which is where definitions appear) 
%v Print a Value 

%V Print a Valuelist (list of Value) 


a program is ill formed, ill typed, or ill behaved, but Impcore has no static type 
system, so faults are triggered only by ill-formed and ill-behaved programs: 


* When it detects an ill-formed program during parsing, the interpreter signals 
a syntax error by calling synerror. 


* When it detects an ill-behaved program at run time, the interpreter signals a 
run-time error by calling runerror. 


Before initiating error recovery, each error-signaling function prints a message. 
For that reason, an error-signaling function's interface resembles print. But be- 
cause different information is available at parse time and at run time, synerror 
and runerror have different interfaces. 

The simpler of the two is runerror. During normal operation, runerror prints 
to standard error and then longjmps to errorjmp. 


47a. (shared function prototypes 43b) += (S295a) <46b 47b> 
void runerror (const char *fmt, ...); 
extern jmp_buf errorjmp; // longjmp here on error 


During unit testing, runerror operates in testing mode, and it behaves a little dif- 
ferently (Section F.5.1, page S182). 

Function synerror is like runerror, except that before its format string, it takes 
an argument of type Sourceloc, which tracks the source-code location being read 
at the time of the error. The location can be printed as part of the error message. 
47b. (shared function prototypes 43b) += (S295a) <47a 47c¢> 

void synerror (Sourceloc src, const char *fmt, ...); 


Error handling, as opposed to error signaling, is implemented by calling setjmp 
on errorjmp. Function setjmp must be called before any error-signaling func- 
tion. It is an unchecked run-time error to call runerror or synerror except when 
a setjmp involving errorjmp is active on the C call stack. 

One common run-time error is that an Impcore function is called with the 
wrong number of arguments. That error is detected by function checkargc. Its pa- 
rameter e holds the call in which the error might occur. 
47c. (shared function prototypes 43b) += (S295a) <47b 

void checkargc(Exp e, int expected, int actual); 
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1.6.2 Implementation of the evaluator 


The evaluator implements Impcore’s semantics. It comprises functions eval and 
evaldef, which evaluate expressions and true definitions. 


Evaluating expressions 


Function eval implements the {| relation from the operational semantics. Calling 
eval(e, €, ¢, ) finds a v, &’, and p’ such that (e,€,¢,p) |) (v,€’,¢, p’), assigns 
p := p' andé := €’, and returns v. Because Greek letters aren’t customary in 
C code, I use these English names: 


€  globals 
@ functions 
p formals 


Function eval is mutually recursive with a private helper function, evallist: 
48a. (eval.c 48a)= 48b > 
static Valuelist evallist(Explist es, Valenv globals, Funenv functions, 
Valenv formals); 


Evaluation of an expression e begins by discovering its syntactic form, using a 
switch on the tag e->alt. 
48b. (eval.c 48a) += <148a 51b> 
Value eval(Exp e, Valenv globals, Funenv functions, Valenv formals) ~ 


switch (e->alt) £ 
case LITERAL: (evaluate e->literal and return the result 48c) 


case VAR: (evaluate e->var and return the result 49a) 
case SET: (evaluate e->set and return the result 49b) 
case IFX: (evaluate e->ifx and return the result 49c) 
case WHILEX: (evaluate e->whilex and return the result 50a) 
case BEGIN: (evaluate e->begin and return the result 50b) 
case APPLY: (evaluate e->apply and return the result 50c) 
3 


assert(0); 
3 
The assertion at the end of eval might seem superfluous, but it isn’t; it helps pro- 
tect me, and you, from mistakes, and it convinces the C compiler that every possi- 
ble case is covered. 

Function eval proceeds by case analysis over the syntactic forms of Exp. Each 
case is written in consultation with the operational semantics: for each syntactic 
form, eval implements the rules that have the form on the left-hand sides of their 
conclusions. 

The LITERAL form appears in the conclusion of just one rule. 


(LITERAL) 

The implementation returns the literal value. 
48c. (evaluate e->literal and return the result 48c)= (48b) 

return e->literal; 
The VAR form appears in the conclusions of two rules. 
eS done (FORMALVAR) 
(vaR(x),£,0, 2) 4) (p(a),&; , p) 

x ¢ dom x € dom 

g u § (GLOBALVAR) 


(var(x),€, 6, 0) 4 (&(2),&, 6, 0) 


A rule can be used only if its premises hold, so the interpreter checks x € dom p, 
which is implemented by calling isvalbound(e->var, formals). If 2 ¢ domp 
and x ¢ dom €, the operational semantics gets stuck—so the interpreter issues an 
error message. Less formally, the interpreter looks for x in the formal-parameter 
environment first, then the global environment. 
49a. (evaluate e->var and return the result 49a) = (48b) 
if (isvalbound(e->var, formals) ) 
return fetchval(e->var, formals); 
else if (isvalbound(e->var, globals)) 
return fetchval(e->var, globals); 
else 
runerror("unbound variable %n", e->var); 
The call to runerror illustrates the convenience of the extensible printer; it uses %n 
to print a Name directly, without needing to convert the Name to a string. 
The SET form is very similar. Again there are two rules, and again they are 
distinguished by testing x € dom p. 


zédomp  (e,€,¢,p) I (v,€',¢,p') 
(SET(2, e),&, dQ, p) a (vu, &', Q, p{x > v}) 


x ¢ dom p G2€ dom & (e,&,¢, p) a (u, €', d, p’) 


(sET(a,€),€,,p) } (v,€/{a + v}, o, p') 


Because both rules require the premise (e, €,, p) |) (v, €’, d, p’), the code evalu- 
ates e (e->set.exp) first, then puts its value in v. 


(FORMALASSIGN) 


(GLOBALASSIGN) 


49b. (evaluate e->set and return the result 49b)= (48b) 
g 


Value v = eval(e->set.exp, globals, functions, formals); 


if (isvalbound(e->set.name, formals) ) 
bindval(e->set.name, v, formals); 
else if (isvalbound(e->set.name, globals)) 
bindval(e->set.name, v, globals); 
else 
runerror("tried to set unbound variable %n in %e", e->set.name, e); 
return v; 


3 
The IF form appears in the conclusions of two rules. 


CE yy p) (v1, €', ¢, 0’) U1 # 0 (e2,€,¢, p’) (v2, €", d, p") 
(IF(e1, €2; €3); g, ¢, p) 1 (v2, ale d, a) 
(IFTRUE) 
) 


(e15€,.0, p) 1 (v1, €', ¢, 0") UL 0 (e3, €', , p a (u3,€", d, p") 
(IF(e1, €2,; €3), g, ¢, p) \ (v3, ue d, pr" 
(IFFALSE) 


Both rules have the same first premise: (e€,,€,¢, 2) |) (v1, €’, d, p’). To get v4, &’, 
and p’, the code calls eval(e->ifx.cond, globals, functions, formals) recur- 
sively. This call may mutate the globals and formals environments, but regardless 
of whether v; = 0, the mutation is safe, because the third premises of both rules 
use the new environments €’ and p’. Comparing v; with zero determines which 
rule should be used: the implementation ends with a recursive call to evaluate ei- 
ther eg (e->ifx. truex) or e3 (e->ifx.falsex). 


49c. (evaluate e->ifx and return the result 49¢c)= (48b) 
if (eval(e->ifx.cond, globals, functions, formals) != 0) 
return eval(e->ifx.truex, globals, functions, formals); 
else 
return eval(e->ifx.falsex, globals, functions, formals); 
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The WHILE form appears in the conclusions of two rules. 


(e1,€, d, p) 1 (v1, €', d, 0’) U1 #0 
(€2, Eh é, p’) ay (v2, ae d, p”’) (WHILE(€1, €2), se d, p"") 4 (v3, ae d, pe 
(WHILE(€1, €2), ie d, p) 1 (v3, sae Q, pl") 


(e1,€, ¢, p) { (v1, €', >, p’) U1 =0 
(WHILE(€1, €2), g ¢, p) a (0, ae Q, p’) 


In the first rule, the premise (WHILE(e1, €2),€”,¢, p”) |} (v3, €", d, p’”) could 
be implemented as a recursive call to eval(e, ...). Bute is always a while loop, so 
I have optimized the code by turning the recursion into iteration. This optimization 
prevents a long WHILE loop from overflowing the C stack. 


(WHILEITERATE) 


(WHILEEND) 


50a. (evaluate e->whilex and return the result 50a)= (48b) 
while (eval(e->whilex.cond, globals, functions, formals) != 0) 
eval(e->whilex.exp, globals, functions, formals); 
return 0; 


The BEGIN form appears in the conclusions of two rules. 


(BEGIN, €, 4,0) ¥ (6.0.0) one peae 
(e1, £0; ¢, Po) a (v1, &1, dg, p1) 
(€2, &1, d, Pi) al (va, £2, d, p2) 

(Cn ona45 ¢, Dan) al (Un, Ens d, Pn) (BEGIN) 


(BEGIN(e), CQ,+0+5 Cn), £0; , Po) al (Vins Ess d, Pn) 


A nonempty BEGIN is implemented by iterating over its subexpressions, leaving the 
last value in variable lastval. If lastval is initialized to zero, the same code also 
implements the empty BEGIN. 


50b. (evaluate e->begin and return the result 50b)= (48b) 
£ 
Value lastval = 0; 
for (Explist es = e->begin; es; es = es->tl) 
lastval = eval(es->hd, globals, functions, formals); 
return lastval; 


3 


Function application appears in the conclusion of the APPLYUSER rule, and also 
in every rule that describes a primitive function. The rule to be implemented de- 
pends on the form of the function, which may be USERDEF or PRIMITIVE. Given a 
function named /f (e->apply.name), the interpreter discovers its form by looking 
at ¢(f), which it stores in local variable f. 


50c. (evaluate e->apply and return the result 50c)= (48b) 
a 
Func f; 
(make f the function denoted by e->apply .name, or call runerror 51a) 
switch (f.alt) £ 
case USERDEF: (apply f.userdef and return the result 51c) 
case PRIMITIVE: (apply f.primitive and return the result 52a) 
default: assert(0); 
3 


If f is not defined as a function, the result is a run-time error. 


51a. (make f the function denoted by e->apply.name, or call runerror 51a) = (50c) 
if (!isfunbound(e->apply.name, functions) ) 
runerror("call to undefined function %n in %e", e->apply.name, e); 
f = fetchfun(e->apply.name, functions); 


When /f is a user-defined function, applying it has something in common with 
begin: arguments €),...,€, have to be evaluated. But where begin keeps only re- 
sult v,, (in variable v in chunk 50b), function application keeps all the result values, 
which it binds into a new environment. 


O(f) = USER((a1,...,2n),e) 
Y1,.--,%y all distinct 


(e1, 0, ¢, Po) a (v1, 61, d, /1) 


(Ons En—1) ¢, Pn—1) 4 (Un, aay ¢, Pn) 
ae ¢, {x1 FH UL, +++) En b> Un }) ay (Ove Q, p') 
(APPLY(f, E1,-++, Crs £0; d, po) a (v, eh Q, Pn) 


Values U1,...,Un, are returned by auxiliary function evallist, which is given 
€1,---,€n along with €9, ¢, and po. It evaluates e1,...,e, in order, and it mu- 
tates the environments so that when it is finished, globals is €,, and formals is pn. 
Finally, evallist returns the list v,,..., Un. 


(APPLYUSER) 


51b. (eval.c 48a) += <48b 53b> 
static Valuelist evallist(Explist es, Valenv globals, Funenv functions, 
Valenv formals) 


t 
if (es == NULL) £ 
return NULL; 
3 else § 
Value v = eval(es->hd, globals, functions, formals); 
return mkVL(v, evallist(es->tl, globals, functions, formals)); 
3 
3 


The rules of Impcore require that es—>hd be evaluated before es->t1. To ensure 
the correct order of evaluation, eval(es->hd, ...) andevallist(es->tl,...) are 
called in separate C statements. Writing both calls as parameters to mkVL would not 
guarantee the correct order. 

The APPLYUSER rule requires that the application have exactly as many argu- 
ments as f is expecting: the list of formal parameters and the list of argument 
expressions both have length n. But in general, they might be different: the for- 


mals %1,...,2n are stored in xs and the actual values v,,..., Um are stored in vs. 

When both are the same length, as confirmed by checkargc, they are used to cre- 

ate the fresh environment mkValenv(xs, vs), which is {21 +> U1,...,2n +> Un}. 

This environment is used to evaluate f’s body. 

51c. (apply f .userdef and return the result 51c)= (50c) 
t 


Namelist xs = f.userdef.formals; 

Valuelist vs = evallist(e->apply.actuals, globals, functions, formals); 
checkargc(e, lengthNL(xs), lengthVL(vs)); 

return eval(f.userdef.body, globals, functions, mkValenv(xs, vs)); 


3 


Each primitive function is applied by code that is specialized to that primitive. 
A primitive is identified by comparing its name to a name made from a known 
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checkarge 47c 
eval 45c 
evallist 48a 


type Explist S292d 


fetchfun 44g 
formals 48b 
type Func A 

functions 48b 
type Funenv 44e 
globals 48b 
isfunbound 45a 
lengthNL A 

lengthVL A 

mkValenv 44f 


mkVL A 

type Namelist 
43a 

runerror 47a 


type Valenv 44e 

type Value 43c 

type Valuelist 
43c 


string. More general techniques for implementing primitives, which are appropri- 
ate for larger languages, are shown in the Chapter 2 (page 154). 


52a. (apply f primitive and return the result 52a)= (50c) 
t 
Valuelist vs = evallist(e->apply.actuals, globals, functions, formals); 
if (f.primitive == strtoname("print")) 
(apply Impcore primitive print to vs and return 52b) 
else if (f.primitive == strtoname("printin") ) 
. ; (apply Impcore primitive print1n to vs and return $299c) 
An imperative core else if (f.primitive == strtoname("printu")) 
(apply Impcore primitive printu to vs and return $299d) 
52 else 
(apply arithmetic primitive to vs and return 52c) 
3 
Only print is implemented here; print1n and printu are in Appendix K. 
52b. (apply Impcore primitive print to vs and return 52b)= (52a) 
z 


checkargc(e, 1, lengthVL(vs)); 
Value v = nthVL(vs, 0); 
print("%v", v); 

return v; 


3 


Each arithmetic primitive expects exactly two arguments, which the code puts 
in C variables v and w. The characters of the primitive’s name go ins. 


52c. (apply arithmetic primitive to vs and return 52c)= (52a) 
t 
checkargc(e, 2, lengthVL(vs)); 
Value v = nthVL(vs, 0); 
Value w = nthVL(vs, 1); 
const char *s = nametostr(f.primitive); 
(if operation s would overflow on v andw, call runerror 53a) 
(return a function of v and w determined by s 52d) 
3 


Ignoring the possibility of overflow, each Impcore primitive can be imple- 
mented by the corresponding operation in C. The primitive’s name is synonymous 
with its first character, s[0]. 
52d. (return a function of v and w determined by s 52d)= (52c) 

assert(strlen(s) == 1); 
switch (s[@]) ¢ 


case '<': return v < w; 
case '>': return v > w; 
case '=': return v == w; 
case 't!': return v + w; 
case '-': return v - w; 
case '*': return v * w; 
case '/': if (w == 0) 


runerror("division by zero in %e", e); 
return v / w; 
default: assert(0); 
3 
But the interpreter cannot ignore the possibility of overflow. The rules of Impcore 
are different from the rules of C, and if the result of an arithmetic operation does 
not fit in the range —2°! to 23!, the operation causes a checked run-time error. 


The error is detected and signaled by function checkarith, which is defined in Ap- 
pendix F. 


53a. (if operation s would overflow on v and w, call runerror 53a) = (52c) 
checkarith(s[0], v, w, 32); 


Evaluating true definitions 


As noted on page 24, definitions are divided into two forms: The true defini- 
tions can differ in each language; Impcore’s true definitions include val and 
define. The extended definitions are shared across languages; they include use 
and check-expect. True definitions have an operational semantics; extended def- 
initions don’t. And true definitions are evaluated by code that is explained here; 
extended definitions are evaluated by code in the Supplement. 

The — relation on the true definitions is implemented by function evaldef. 
Calling evaldef(d, €, ¢, echo) finds a €’ and ¢’ such that (d,€,¢) > (€',¢’), and 
evaldef mutates the C representation of the environments so the global-variable 
environment becomes €’ and the function environment becomes ¢’. If echo is 
ECHOING, evaldef also prints the interpreter’s response to the user’s input. Printing 
the response is evaldef’s job because only evaldef can tell whether to print a value 
(for EXP and VAL) or a name (for DEFINE). 

Just like eval, evaldef looks at the syntactic form of d and implements what- 
ever rules have that form in their conclusions. 
58b. (eval.c 48a) += <51b 

void evaldef(Def d, Valenv globals, Funenv functions, Echo echo) £ 

switch (d->alt) £ 

case VAL: 
(evaluate d->val, mutating globals 53c) 
return; 

case EXP: 
(evaluate d->exp and possibly print the result 54a) 
return; 

case DEFINE: 
(evaluate d->define, mutating functions 54b) 
return; 


3 


assert(Q); 


3 
A VAL form updates €. 


(6,6 Oth) 4 (6, b,0") 
(vaL(x,€),£,0) + (f'{@ - v}, ¢) 


The premise shows that value v and environment €’ are obtained by calling eval. 
This call uses an empty environment as p. In the conclusion, the new environ- 
ment €’ is retained, and the value of the expression, v, is bound to x in it. Value v 
may also be printed. 


(DEFINEGLOBAL) 


53c. (evaluate d->val, mutating globals 53c)= (53b) 
£ 
Value v = eval(d->val.exp, globals, functions, mkValenv(NULL, NULL)); 
bindval(d->val.name, v, globals); 
if (echo == ECHOING) 
print("%v\n", v); 
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bindval 45b 
checkarge 47c 
checkarith S187b 


type Def A 
type Echo S$293f 
eval 45c 
evallist 48a 
formals 48b 


functions 48b 
type Funenv 44e 
globals 48b 
lengthVL A 
mkValenv 44f 
nametostr 43b 


nthVL A 
print $176d 
runerror 47a 


strtoname  43b 
type Valenv 44e 
type Value 43c 
type Valuelist 
43c 


An EXP form also updates €, just as if it were a definition of it. 


(6,6 th) 4 (65 6,0) 
(ExP(e),£,@) — (é'{it > v}, ) 


54a. (evaluate d->exp and possibly print the result 54a)= (53b) 
g 


(EVALEXP) 


Value v = eval(d->exp, globals, functions, mkValenv(NULL, NULL)); 
bindval(strtoname("it"), v, globals); 


An imperative core if (echo == ECHOING) 
print ("%v\n", v); 


54 3 


ADEFINE form updates ¢. The implementation may print the name of the func- 
tion being defined. 


Y1,...,%y all distinct 


(DEFINE(f, (@1,.--,2n),€),§, 6) > (€, d{ f  USER((21,...,2n),e)}) 


(DEFINEFUNCTION) 


54b. (evaluate d->define, mutating functions 54b)= (53b) 
bindfun(d->define.name, mkUserdef(d->define.userfun), functions); 
if (echo == ECHOING) 
print("%n\n", d->define.name); 


The evaluator does not check to see that the 71,..., 2, are all distinct—the 2,’s 
are checked when the definition is parsed, by function check_def_duplicates in 
chunk S208e. 


1.6.3 Implementation of environments 


An environment is represented by a pair of lists; one holds names and the other 
holds the corresponding values. The lists have the same length. (A search tree or 
hash table would be enable faster search but would be more complicated.) 
54c. (env.c 54c)= 54d> 
struct Valenv { 
Namelist xs; 
Valuelist vs; 
// invariant: lists have the same length 
3; 

Given the representation, creating an environment is simple. To prevent the 
invariant from being violated, the code asserts that xs and vs have equal length. 
54d. (env.c 54c) += <54c 55a> 

Valenv mkValenv(Namelist xs, Valuelist vs) { 
Valenv env = malloc(sizeof(*env)); 
assert(env != NULL); 
assert(lengthNL(xs) == lengthVL(vs)); 
env->xXsS = XS; 
env->vs = VS; 
return env; 


3 


The list of names xs is searched by three functions: fetchval, isvalbound, 
and bindval. Behind the scenes, that search is implemented just once, in private 
function findval. Given a name x, it searches the environment. If it doesn’t find x, 
it returns NULL. If it does find x, it returns a pointer to the value associated with x. 


The pointer can be used to test for binding (isvalbound), to fetch a bound value 
(fetchval), or to change an existing binding (bindval). 


55a. (env.c 54c) += 154d 55b> 
static Value* findval(Name x, Valenv env) £ 
Namelist xs; 
Valuelist vs; 
for (xs=env->xs, vS=env->vs; xs && vs; xS=xs->tl, vs=vs->t1) 
if (x == xs->hd) 
return &vs->hd; 
return NULL; 
3 
Aname is bound if there is a value associated with it. 
55b. (env.c 54c) += 55a 55c> 
bool isvalbound(Name name, Valenv env) £ 
return findval(name, env) != NULL; 
3 
A value is fetched through the pointer returned by findval, if any. 
55e. (env.c 54c) += <55b 55d> 


Value fetchval(Name name, Valenv env) ¢ 
Value *vp = findval(name, env); 
assert(vp != NULL); 
return *vp; 


3 


A new binding could be added to an environment by inserting a new name 
and value at the beginning of xs and vs. But I can get away with an optimization. 
If « € dom, instead of extending p by making p{x +> v}, I overwrite the old 
binding of x. This optimization is safe only because no program written in Imp- 
core can tell that it is there. Proving that the optimization is safe requires reason- 
ing about the rules of the operational semantics, which show that in any context 
where p{x +> vu} appears, the old p(x) can’t affect any evaluations (Exercise 29 on 
page 85). 
55d. (env.c 54c) += <155¢ 

void bindval(Name name, Value val, Valenv env) ¢ 
Value *vp = findval(name, env); 
if (vp != NULL) 
*vp = val; 
else ¢ 
env->xs = mkNL(name, env->xs); 


// safe optimization 


env->vs = mkVL(val, env->vs); 


3 


The code above implements value environments. To preserve type safety, the 
same data structure and operations are implemented a second time using Func in- 
stead of Value. That code appears in Appendix K. 


1.7. OPERATIONAL SEMANTICS REVISITED: PROOFS 


Calling eval(e, €, d, p) is supposed to return a value v if and only if there is a proof 
of the judgment (e, €,¢, p) |) (v, €, ¢, p) using the rules from Section 1.5. Proofs 
in programming languages are not very interesting; or rather, they are interesting 
primarily when they are wrong. Like a bug in a program, a wrong proof tells you 
that you made a mistake (in your language design, not your code). Anda good proof 
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doesn’t have to be interesting, because it conveys certainty. A proof can guarantee 
that your program or your programming language does what you think it does. 


1.7.1 Proofs about evaluation: Theory 


A proof about the evaluation of code—that is, about a call to eval or evaldef—takes 
the form of a derivation. This form of proof, which is borrowed from formal logic, 
is a tree in which each node is an instance of an inference rule; an instance of a 
rule is obtained by substituting for the rule’s metavariables. If every substitution 
is done consistently, and if, in the resulting derivation, every proposition holds, 
then the derivation is valid. A valid derivation justifies the judgment claimed in the 
conclusion of its root. These concepts are illustrated in the next few pages. 


How do we write derivations? 


A derivation is also called a proof tree; the root contains the conclusion, and each 
subtree is also a derivation. A derivation tree is written with its root at the bottom; 
as in a single rule, the conclusion of a derivation appears on the bottom, below a 
horizontal line. The leaf nodes appear at the top; each leaf node is an instance of 
an inference rule that has no evaluation judgments among its premises, like the 
LITERAL rule or the FORMALVAR rule (page 32). A leaf node corresponds to a com- 
putation in which eval returns a result without making a recursive call. 

Each node in a derivation tree is obtained by instantiating a rule and then de- 
riving that rule’s premises. Instantiation may substitute for none, some, or all of 
a rule’s metavariables. Substitution that replaces all metavariables, leaving only 
complete environments, syntax, and data, describes a single run of eval. For ex- 
ample, suppose a literal 83 is evaluated in a context where there are no global vari- 
ables, no functions, and no formal parameters: 


eval(mkLiteral(83), 
mkValenv(NULL, NULL), mkFunenv(NULL, NULL), mkValenv(NULL, NULL)); 


The resulting run can be described by an instance of the LITERAL rule. The rule 
appears in the semantics as follows: 


. (LITERAL) 


The instance that describes the run is obtained by substituting 83 for v, {} for €, 
{} for d, and {} for p: 


(LITERAL(83), {}, {}, {}) 4 (83, (}, Uh t}) 


Because the LITERAL rule has no premises above the line, this instance is a com- 
plete, valid derivation all by itself. 

The preceding example is awfully specific. In practice, a literal 83 evaluates 
to 83 regardless of the presence of functions or variables—and the evaluation does 
not change the values of any variables. To prove that, I create a different instance 
of LITERAL, in which I substitute only for v, leaving €, ¢, and pas they are written 
in the rule: 


(LITERAL (83), , 0, p) 4) (83, €, 6, p) 


This instance is also a complete, valid derivation, and it describes the evaluation of 
a literal 83 in any possible environment. 


A complete derivation tree ends in a single rule, but if that rule has evaluation 
judgments above the line, like the APPLY rules, then each of those judgments—the 
premises—must be derived as well. A complete derivation follows this schema: 


Derivation of Derivation of 
first premise last premise $1.7 
Conciaion Operational 
semantics 


This schema assumes that every premise is justified by a derivation. In practice, revisited: Proofs 
only an evaluation judgment can be justified by a derivation. Other premises, like 
x € dom por p(x) = 3, are justified by appealing to what we know about x and p. 

As an example of a derivation tree with more than one node (which is wide 
enough to extend into the margin), I describe the evaluation of (+ (* x x) (* yy)), 
which computes the sum of two squares. It’s evaluated in an environment where 
p binds x to 3 and y to 4. 


57 


xEdomp p(x) =3 x€domp p(x) =3 
FORMALVAR z 3 € % ) (VAR(x) € c yy B € F; ) FORMALVAR 
APPLYMUL (vaR( Js dna SPP 9S) . SP) P. 
APPLYADD (APPLY( , VAR(x), VAR(x)), €, ¢, p) al) ( as ¢, p) 


(APPLY(+, APPLY(*, VAR(x), VAR(x)), APPLY(*, VAR(y), VAR(y))),€, 9, p) 4 (25, €, ¢, 0) 


Each node is labeled with the name of the rule to which it corresponds. Because 
derivation trees take so much space, I’ve elided the subtree that proves 


(APPLY(*, VAR(y), VAR(y)),€,;p) 4 (16, £, 0, p)- 


Derivation trees can get big, and to fit them into small spaces, we often 
take liberties with notation. For example, instead of writing abstract syntax like 
APPLY(*, VAR(y), VAR(y)), we can write concrete syntax like (* y y). The resulting 
notation is easier to digest, but it is less obvious that each node is an instance of a 
semantic rule: 


xE€domp = p(x) =3 x€domp = p(x) =3 
FORMALVAR FORMALVAR 
A (x,€, 0, p) 4 (3, €, ¢, p) (x, €,, p) 1 (3, € , p) 
PPLYMUL 
(Cx x), 5) ) 4 (9,8; oP) 
APPLYADD 


(C+ (#x x) (Fy y)),€, 6, p) 4 (25, &, 4, p) 


Even if I use a smaller font and don’t label the nodes, the full derivation tree sticks 
even further into the margin: 


x€domp = p(x) = 3 x€domp p(x)=3 yEedomp = p(y)=4 y€domp p(y)=4 
(x € , p) 4 (3, & 6; p) (x € 5p) ¥ (3,6,6,0) (v,€,,0) + (4,66, 0) (y,& 0p) 4 (4, & &; p) 
(c* x x), & d, p) 4 (9,€, , p) (CF yy). €, d, p) a) (16, €, gp) 


(C+ (#xx) (FY Y)),€, 0b, 0) Y (25, € 6, p) 
What is a valid derivation? 


A derivation is valid if every node is obtained by instantiating a rule and every 
premise is justified (either by a valid subderivation or by other means). To explain 
validity, it helps to name the rule that is instantiated at the root. A derivation D is 
a valid derivation ending in an application of rule 7 when all of these conditions 
hold: 


* The derivation is obtained by substituting for the metavariables in ®. Sub- 
stitution must respect the intent of the metavariables: only a well-formed 
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expression may be substituted for e, a value for v, a well-formed environ- 
ment for p, and so on. While whatever is substituted must be well formed, 
it need not be completely specified: whatever is substituted for a metavar- 
iable may itself contain metavariables. For example, IF(€1, €2, €3) may be 
substituted for e. 


* Rule R may include evaluation judgments above the line, as premises. After 
substitution, each of these premises must be justified by a derivation of its 
own. 


+ After substitution, every other premise in rule R must also be justified. 
Premises that aren't evaluation judgments are usually justified by set theory, 
arithmetic, or appeal to assumptions. 

As an example, if n is a formal parameter, evaluating (set n @) sets n to zero 
and returns zero. I want to derive the judgment 


(SET(n, LITERAL(0)), €, 4, p) 4) (0,€, ¢, p{n +> O}). 


This goal judgment is derived by a derivation D that ends in rule FORMALASSIGN, 
which I reproduce here: 


cedomp  (¢,6,¢,p) 4 (v,€, 6,0’) 
(SET(z, e), &3 d, p) a (v, &, Q, p{x > v}) 
To get the conclusion of FORMALASSIGN to match the goal, I substitute n for z, 


LITERAL(O) for e, € for €’, 0 for v, and p for p’. With that substitution, my derivation 
in progress looks like this: 


né€domp _(LiTERAL(0),£,@,2) 4 (0,6, 6, 0) 
(SET(n, LITERAL(0)), £9, p) 4) (0,, 6, p{n ++ 0}) 


To complete the derivation, I derive judgment (LITERAL(0), €, ¢, p) 4) (0,€, 4, p), 
with a new derivation D,. Derivation D, endsin rule LITERAL, and to construct Dj, 
I substitute 0 for v in rule LITERAL. Rule LITERAL has no premises, so that substi- 
tution completes D,: 


. (FORMALASSIGN) 


P= Trrprat(0),6,d,p) 0 (0.60.0) 


Plugging D, into my previous work completes D: 


n€domp —_(LiTERAL(0),£,¢,p) 4 (0,66, 
(sET(n, LITERAL(0)), £9, p) 4} (0, 6, p{n + 0}) 


For derivation D to be valid, premise n € dom p must also be proved. It’s true by 
assumption: n is a formal parameter, which is what n € dom p means. 


How do we construct valid derivations? 


A derivation is valid if we substitute consistently for each metavariable, replace 
every evaluation premise with a valid derivation, and can prove the other premises. 
But how do we know what to substitute? There’s an algorithm, and it’s the same 
algorithm that’s used in eval to interpret code. That’s no surprise—every derivation 
tree is intimately related to an application of eval. The derivation expresses, in a 
data structure, the steps that eval goes through to interpret the code. 

To construct a derivation, we start with an initial state—the left-hand side of an 
evaluation judgment. We usually know some or all of the syntax, and we may know 
something about environments as well. The algorithm works like this: 


1. Find a rule # whose conclusion matches the left-hand side we are inter- 
ested in. By “matches,” I mean that the left-hand side we are interested can 
be obtained by substituting for metavariables in the conclusion of R. For ex- 
ample, in the derivation for the SET expression above, only two rules can 
conclude in a SET expression: FORMALASSIGN and GLOBALASSIGN. 


In the Impcore interpreter, the “find a rule” step corresponds to the main 
switch statement in function eval (chunk 48b), which identifies possible 
rules by looking at e->alt. 


2. Substitute in R so that the left-hand side of the conclusion is equal to the 
initial state of interest. Now look at each of R’s premises. 


3. If a premise does not involve an evaluation judgment, see if it is provable. 
If so, continue building the derivation. If not, try some other rule. 


In an interpreter, provability corresponds to a check on run-time data. 
Premises like x € dom€ or x ¢ domp are checked by calling isvalbound, 
and premises like v; # 0 or v1 = 0 are checked by comparing a run-time 
value with 0. 


4. Ifa premise does involve an evaluation judgment, recursively build a deriva- 
tion of that judgment, starting with the right-hand side. In the Impcore in- 
terpreter, recursively building a derivation corresponds to a recursive call to 
eval. 


This algorithm eventually dictates what needs to be substituted on the right-hand 
side of the evaluation judgment. An example appears in Figure 1.7, which con- 
structs a derivation for (set n (+n 1)) inan environmentin which nis 7. Figure 1.7 
shows a sequence of snapshots; in each one, the partially constructed derivation 
is shown in black and the parts that are not yet constructed are shown in gray. 
The derivation begins with the expression (set n (+n 1)) and an environment p 
in which p(n) = 8. (Because € and ¢ do not take part and do not change, they are 
omitted to save space.) Each step fills something in; first, check n € dom 9; next, 
evaluate (+n 1), and so on. The sketch should suggest that the derivation, which 
is a data structure, is a spacelike representation of a timelike computation. This is 
true of every derivation. 


What can we do with derivations? 


If we know something about the environments, we can use derivation trees to an- 
swer questions about the evaluation of expressions and definitions. One example 
is the evaluation of the expression in Exercise 12 on page 77. This kind of appli- 
cation of the language semantics is called the theory of the language. But we can 
answer much more interesting questions if we prove facts about derivations. For ex- 
ample, in Impcore, the expression (if x x 0) is always equivalent to x (Exercise 13 
on page 77). Because a computation is a sequence of events in time, proving facts 
about computations can be difficult. But if every terminating computation is de- 
scribed by a derivation, a derivation is just a data structure, and proving facts about 
data structures is much easier. Reasoning about derivations is called metatheory. 


1.7.2 Proofs about derivations: Metatheory 


If you already know that you want to study metatheory, you'll soon need another 
book. This book only suggests what metatheory can do, so you can figure out if you 
want to study it more deeply. 
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n€ domp 


(n,p) (7, p) (1, p) U (1, p) 


n€ domp ((#n1),p) Y (8, p) 


n€ dom p 


(n,p) V (7,p) (1, p) 4 (1, p) 


n€ domp (C+ 1), p) Y (8, p) 


((set n (+n 1)),p) Y (8, p{n ++ 8}) 


oe 


n€ domp 


(n,p) (7, p) (1, p) ¥ (1, p) 


n€domp ((+n 1), p) 4 (8, p) 


((set n (+n 1)), p) 4 (8, p{n > 8}) 


n€ dom p 
(n,e) 4 (7p) (4,0) 4 (1, e) 


n€ domp (c+ 1), p) 4 (8, p) 


((set n (+1 1)),p) | (8, p{n +> 8}) 


6 


n€ domp 


(n,p) 4 (7,p) (4,9) I (1, p) 


n€domp (c+ 1), p) 4 (8, p) 


((set n (+n 1)),p) 4 (8, p{n + 8}) 


n€ dom p 
(n,e) 4 (7p) (4,0) 4 (1, e) 


né€domp (C+ 1), p) 4 (8, p) 


((set n (+1 1)),p) | (8, p{n +> 8}) 


n€ domp 


(n,p) 4 (7,0) (A,p) 4 (1, p) 


n € dom p (C+ 1), p) Y (8, p) 


((set n (+ 1)),p) 4 (8, p{n > 8}) 


n€ dom p 
(n,e) 4 (7p) (4,0) 4 (1, 2) 


né€ domp (C+ 1), p) 4 (8, p) 


((set n (+1 1)),p) | (8, p{n +> 8}) 


((set n (+n 1)),p) U (8, p{n > 8}) 


n€ dom p 
(n,p) 4 (7,9) (4,p) 4 (1, p) 
(+1), p) 4 (8, p) 
((set n (+n 1)),p) | (8, p{n +> 8}) 


n€ domp 


Figure 1.7: Construction of a derivation (omitting unchanging € and ¢) 


Metatheory can determine the validity of a claim like this: in any Impcore pro- 
gram, the expression (+ x 0) can be replaced by just x, and this replacement doesn’t 
change any output of the program. This claim could be important to a compiler 
writer, who might use it to create an “optimization” that improves performance. 
If you're going to create an optimization, you must be certain that it doesn’t change 
the meaning of any program. Certainty can be supplied by a metatheoretic proof. 

What can we prove about a program that evaluates (+ x 0)? If a derivation ex- 
ists, it will contain a judgment of the form 


((+x 0),&, 6, p) 4 (v, &', d, p’). 


That judgment will be the root of a subderivation. That subderivation must apply 
a rule that permits the application of the + primitive on the left-hand side of its 
conclusion. So just like the interpreter code in chunk 48b, a proof has to consider 
inference rules whose conclusions can contain APPLY(+,...). 

Two such rules appear in Section 1.5.6: APPLYUSER and APPLYADD. And the 
claim is false! If f(+) refers to a user-defined function, the APPLYUSER rule kicks in, 
and it is not safe to replace (+ x 0) with x. Here’s a demonstration: 

60. (terrifying transcript 60)= 
-> (define + (x y) y) 
-> (define addzero (x) (+ x 0)) 
-> (addzero 99) 


; No Sane person would do this 


-> (define addzeroe (x) x) 
-> (addzero2 99) 


If a compiler writer wants to be able to replace an occurrence of (+ x 0) with x, 
they will first have to prove that the environment ¢ in which (+ x 0) is evaluated 
never binds + to a user-defined function. (Compilers typically include lots of infras- 
tructure for proving facts about environments, but such infrastructure is beyond 
the scope of this book.) 

Proving facts about derivations is metatheory. Metatheory enables you to prove 
properties like these: 


Expression (if x x 0) is equivalent to x (Exercise 13). 


If evaluation of a while loop terminates, its value is zero (Exercise 23). 


Evaluating an expression can’t create a new variable (Exercise 24). 
g 


In Impcore, evaluating an expression in the same context always produces 
the same result—which isn’t true of languages that support parallel execution 
(Exercise 27). 


Impcore programs can be evaluated using a stack of mutable environments, 
as the implementation in Section 1.6 does (Exercise 29). 


Results like these are useful, but one requires a long, detailed proof. 


1.7.3 How to attempt a metatheoretic proof 


A metatheoretic proof works by induction on the structure of valid derivations. 
A derivation is atree, anda proof can assume that an induction hypothesis holds for 
any proper subtree. Or, if you prefer, a metatheorem can be proved by induction 
on the height of a derivation tree. 

A valid derivation can end in any rule, so a proof by induction on a derivation’s 
structure has a case for every rule. In a language as big as Impcore, that’s a lot 
of cases. In this book, each case is presented in exactly the same way. As an exam- 
ple, here’s a case from the proof that evaluating an expression doesn’t create any 
new global variables. The theorem, which is also the induction hypothesis, says 
that if derivation D proves (e, €, 4, p) 4) (uv, €’, d, p’), then dom € = dom €’: 


¢ When the last rule used in D is FORMALASSIGN, the derivation must have the 
following form: 


Di 
LE dom p (e1, €, , p) a (v, €, d, fm) 
(SET(x, €1),€, ¢, p) a (u,€, Q, p {x nd v}) 


The form of e is SET(x, e;). Our obligation is to prove that the induction hy- 
pothesis holds for the judgment below the line. We must therefore prove 
that dom€ = dom€’. But because derivation D, is smaller than deriva- 
tion D, we are permitted to assume the induction hypothesis, which tells us 
that dom € = dom €’. Our obligation is met. 


FORMALASSIGN 


This example, like all the cases in my metatheoretic proofs, uses the following tem- 
plate: 


1. When the last rule used in D is RULENAME, and RULENAME has conclu- 
sion C' and premises P, to P,,, the derivation must have the following form: 


Die!» EP 
D = —WH— RULENAME 
C 
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Commentary: The conclusion C is the evaluation judgment of which D is a proof. 
If any particular P; is also an evaluation judgment, I write its derivation above it, 
as in 
Di 
Pi 


>|3 


D= RULENAME 


Q| |S 


A premise like “x ¢ dom p” is not an evaluation judgment and is not supported 
by a subderivation. 


2. The form of e is syntactic form, and whatever additional analysis goes with that 
syntactic form and with rule RULENAME. 


3. Our obligation is to prove that the induction hypothesis holds for the judg- 
ment below the line. We must therefore prove whatever it is. 


4. Identifying each premise P; that is an evaluation judgment, because derivation 
D, is strictly smaller than derivation D, we are permitted to assume that 
the induction hypothesis applies to derivation D;. This assumption gives us 
whatever it gives us. 


5. From the truth of premises P, to P,,, plus the information from the induction 
hypothesis, we show that the induction hypothesis holds for the judgment below 
the line. 


6. Our obligation is met. 


This template has served me well, but part of it may surprise you: it doesn’t dis- 
tinguish between “base cases” and “inductive cases.” The distinction exists—a base 
case is one that has no evaluation judgments above the line—but in a programming- 
language proof, the distinction is not terribly useful. For example, base cases might 
or might not be easy, and they might or might not fail. 

The template is instantiated for every case in a proof. As a demonstration, I in- 
stantiate the template to try to prove the metatheoretic conjecture, 


If an expression e is evaluated successfully, then every variable in e is 


defined. 


(This conjecture isn’t true, but that’s a good thing—we learn the most from the 
things we try to prove that aren't so. To maximize your own learning, you might 
pause and think about which case or cases of the proof are going to fail.) 

To begin, I state my conjecture formally. And that means I must formalize the 
idea of “every variable in e.” I use the function fv(e), short for “free variables of e,” 
which is defined in Figure 1.8 on the facing page. Figure 1.8 uses a simplified dialect 
of Impcore, which makes the metatheoretic proof a little easier: 


+ Simplified Impcore has no begin expression. 


* In Simplified Impcore, every function application has exactly two argu- 
ments. 


(You can work out how to eliminate begin in Exercise 14 on page 79.) Informally 
speaking, fv(e) is the set of variables mentioned in e. A variable can be mentioned 
directly only in a VAR expression or in a SET expression. In other forms of expres- 
sion, the free variables are the free variables of the subexpressions. 


fv (IF(e1, €2,€3 
fv (WHILE(e1, e2 
fv (APPLY(f, e1, €2 


Figure 1.8: Free variables of an expression in Simplified Impcore 


Now I can state my conjecture precisely and formally: if D is a valid derivation 


of (ce, €,, p) |) (vu, &, d, p’), then fv(e) C dom € U dom p. This conjecture is also 
my induction hypothesis. 


I now instantiate the proof template for each rule of Simplified Impcore. (Rules 


are listed in Figure 1.11 on page 78.) 


* When the last rule used in D is LITERAL, the derivation must have the fol- 
lowing form: 


D= LITERAL 


The form of € is LITERAL(v). Our obligation is to prove that the induction 
hypothesis holds for the judgment below the line. We must therefore prove 
fv(LITERAL(v)) C dom € U dom p. According to the definition of fv in Fig- 
ure 1.8, fv(LITERAL(v)) = Q, and the empty set is a subset of any set. Our 
obligation is met. 


When the last rule used in D is FORMALVAR, the derivation must have the 
following form: 


x € dom p 


(var(x),€, 6, p) 4 (p(x), €, 4, p) 


The form of e is VAR(x). Our obligation is to prove that the induction hy- 
pothesis holds for the judgment below the line. We must therefore prove 
fv(vaR(x)) C dom €Udom p. According to the definition of fv in Figure 1.8, 
fv(vaR(a)) = {a}. And from the first and only premise of the derivation, 
we know that x € dom p. Therefore 


FORMALVAR 


fv(vaR(x)) = {x} C domp C (dompU domé). 


Our obligation is met. 


When the last rule used in D is GLOBALVAR, the derivation must have the 
following form: 


x¢domp 2«€domé 
(vaR(x),£, 0,0) 4 (E(x), § % P) 
The form of e is VAR(x). Our obligation is to prove that the induction hy- 


pothesis holds for the judgment below the line. We must therefore prove 
fv(vaR(x)) C dom €Udom p. According to the definition of fv in Figure 1.8, 


GLOBALVAR 
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fv(vAR(a)) = {x}. And from the second premise of the derivation, we know 
that x € dom €. Therefore 


fv(vaR(a)) = {x} C dom€ C (dompU dom 6). 


Our obligation is met. 


When the last rule used in D is FORMALASSIGN, the derivation must have the 
following form: 


Di 
= LE dom p (e1,&, ?, p) 1 (u,€', 9, p’) 
(sET(z, €1), 3 ¢, p) a (v, e3 d, p {x ad v}) 


The form of e is SET(x,e,). Our obligation is to prove that the induction 
hypothesis holds for the judgment below the line. We must therefore prove 
that fv(SET(a#,e1)) C dom U dom p. According to the definition of fv in 
Figure 1.8, fv(SET(x, e1)) = {x} U fv(ez). It therefore suffices to prove the 
following two inclusions: 


FORMALASSIGN 


(a) {a} C dom Udomp. 
(b) fv(e1) C dom € Udom p. 


From the first premise of the derivation, we know that x € dom p, and as be- 
fore, that implies (a). From the second premise of the derivation, we can ap- 
ply the induction hypothesis to D,, which gives us (b). Our obligation is met. 


When the last rule used in D is GLOBALASSIGN, the reasoning is so similar 
to what we have already done that it’s not worth repeating. 


When the last rule used in D is IFTRUE, the derivation must have the follow- 
ing form: 


dD, Do 


(e1,€, >, p) 1 (v1, €',, p’) U1 # 0 (e2, €', ¢, p') a (v2, €",¢, p") 


D= 


IFTRUE 


(IF(€1, €2; €3), &; ¢, p) a (v2, ae Q, Oy 


The form of e is IF(€1, €2, €3). Our obligation is to prove that the induction 
hypothesis holds for the judgment below the line. We must therefore prove 
fv (IF(e€1, €2,e3)) C domé U dome. According to the definition of fv in 
Figure 1.8, fv(IF(e1, €2, e3)) = fv(e1) Ufv(e2) Ufv(e3). It therefore suffices 
to prove the following three inclusions: 


(a) fv(e,) C dom € Udom p. 
(b) fv(e2) C dom € U dom p. 
(c) fv(e3) C dom € U dom p. 


By applying the induction hypothesis to D,, we get (a). By applying the 
induction hypothesis to Dz, we get (b). But there is no subderivation cor- 
responding to the evaluation of e3. And in fact we cannot prove that 
fv(e3) C domé U dom p, because it isn’t true! Expression e€3 is not eval- 
uated, and its free variables might not be defined. Here’s an example: 
64. (transcript 12a) += 129 
-> (if 1 7 undefined) 
7 


Our obligation cannot be met. 


* I could continue with the other cases. The proof fails for IFFALSE as well as 
IFTRUE, but it succeeds for EMPTYBEGIN, BEGIN, and APPLYUSER. Analysis 
of rules WHILEITERATE and WHILEEND is left for Exercise 26. 


The conjecture isn’t actually a theorem, and in the process of working out a proof, 
I found a counterexample. To guarantee that every variable in an expression is 
defined, we would need something stronger than a successful evaluation. Like a 
type checker, for example (Chapter 6). 


1.7.4 Why bother with semantics, proofs, theory, and metatheory? 


What’s up with all the Greek letters and horizontal lines? What’s the point? Isn't it 
easier just to look at the code? No, because an operational semantics leaves out all 
sorts of “implementation details” that would otherwise impede our understanding 
of how a language works. For example, to a compiler writer, the representation 
of an environment is super important—where values are stored has a huge impact 
on the performance of programs. But if we just want to understand how programs 
behave, we don't care. And once you get used to the Greek letters and horizontal 
lines, you'll find them easier to read than code—much easier. The point of opera- 
tional semantics is to combine precision and understanding. That’s why when you 
find a new idea in a professional paper, the idea is usually nailed down using op- 
erational semantics. When you can read operational semantics, you'll be able to 
learn about new ideas for yourself, direct from the sources, instead of having to 
find somebody to explain them to you. 

What about proof theory and metatheory? Theory involves making derivations— 
typically one derivation at a time. It can guide an implementor, because it tells 
them just what each construct is supposed to do. In principle, theory could also 
guide a programmer, who also needs to know what programs are supposed to 
do. But in practice, operational semantics works at too low a level. A program- 
mer can more effectively use something like the algebraic laws in the next chapter. 
The programmer—or perhaps a specialist—uses operational semantics to show that 
the laws are sound, and after that, programming proceeds by appealing to the laws, 
not to the operational semantics directly. 

So theory is good for building implementations and for establishing algebraic 
laws, both of which are useful for programmers. What is metatheory good for? 
Metatheory involves reasoning about derivations. In particular, metatheory can re- 
veal universal truths about derivations, which correspond to facts about all pro- 
grams in a given language. Such truths might interest implementors, program- 
mers, or even policy makers. For example, 


+ If youre implementing C or Impcore, you can keep the local variables and 
formal parameters of all functions on a stack (Exercise 29). This stack is 
called the call stack. 


In Impcore, no function can change the value of a formal parameter (or local 
variable) belonging to any other function. 


In C, a function can change the value of a formal parameter (or local vari- 
able) belonging to another function, but only if at some point the & operator 
was applied to the parameter or variable in question—or if somebody has 
exploited “undefined behavior” with pointers. 
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¢ If an ordinary device driver fails, it can take down a whole operating-system 
kernel, resulting in a “blue screen of death.” But if a device driver is writ- 
ten in the special-purpose language Sing#, the worst it can do is take away 
its device—metatheory guarantees that the operating-system kernel and the 
other drivers are unaffected. 


Serious metatheory is well worth learning; this book provides just a taste. Doing a 
few of the exercises can show you the difference between theory and metatheory, 
give you an idea of how a metatheoretic proof is structured, and give you an idea of 
what metatheory can do. 


1.8 EXTENDING IMPCORE 


Impcore is a “starter kit” for learning about abstract syntax, operational semantics, 
and interpreters. It’s not a useful programming language—useful languages offer 
more values than just machine integers. (New values are coming in Chapter 2.) But 
even with only integer values, Impcore can still be extended in two useful ways: 
with local variables and with looping constructs. 

Any language that even pretends to be useful offers some species of local vari- 
ables. Impcore can offer them too (Exercise 30 on page 86). Local variables can be 
used to define functions like the one shown in Figure 1.9 on the next page, which 
adds up the odd numbers from 1 to n. 

Adding local variables requires you to change the abstract syntax of Userfun so 
that it includes not only a body and a list of formal parameters, but also a list of local 
variables. And to account for the semantics of local variables, you’ll need to change 
the evaluator. But other kinds of extensions, including new looping constructs, can 
be implemented without touching the abstract syntax or the evaluator. You add only 
concrete syntax, which is implemented in terms of the abstract syntax you have 
already. This kind of new concrete syntax is called syntactic sugar. 

As examples of syntactic sugar, I suggest several new ways to write loops. Let’s 
begin with an ordinary while loop, like this one: 


(while (<= i n) 
(begin 
(set sum (+ sum i)) 
(set i (+ i 2)))) 


The begin might seem like a lot of syntactic overhead. I imagine a new syntactic 
form, which Ill call while*, in which the condition is still a single expression, but 
the body is a sequence of expressions. Now the begin is no longer necessary: 


(while* (<= i n) 
(set sum (+ sum i)) 
(set i (+ i 2))) 


The while* loop can be defined as syntactic sugar: 
(while* condition e€, --+ En) = (while condition (begin e, --: €n)) 


As another example, C’s do. . .while loop executes the body first, then the con- 
dition. In Impcore, we might define a do-while as syntactic sugar: 


(do-while body condition) = (begin body (while condition body) ) 
Finally, C’s complicated four-part for loop can also be defined as syntactic sugar: 


(for pre test post body) = (begin pre (while test (begin body post))) 
P P Ly P 


67. (answer transcript 67)= 
-> (define add-odds-to (n) 
[locals i sum] 
(begin 
(set i 1) 
(set sum 0) 
(while (<= i n) 
(begin 
(set sum (+ sum i)) 
(set i (+ i 2)))) 
sum)) 
-> (add-odds-to 3) 


-> (add-odds-to 5) 


-> (add-odds-to 7) 


Figure 1.9: Programming with local variables 


All these alternatives can be implemented just by modifying Impcore’s parser (Ex- 
ercise 34, page 87). An example can be found in the Supplement (Section G.7, 
page S209). 


1.9 SUMMARY 


Impcore is a toy, but its simple, imperative control constructs—procedure defini- 
tions, conditionals, and loops—model the structure of all procedural languages. 
These constructs are also found in many other languages, including some that de- 
scribe themselves as “object-oriented,” “scripting,” or even “functional.” More im- 
portant, Impcore serves as a tiny, familiar medium with which to introduce two 
foundational ideas: abstract syntax and operational semantics. Finally, Impcore 
introduces the most distinctive feature of this book: the definitional interpreter. 


1.9.1 Key words and phrases 


ABSTRACT MACHINE An abstraction used to evaluate programs in OPERATIONAL 
SEMANTICS. An abstract machine has a state formed from mathematical ob- 
jects; typical objects include ENVIRONMENTS, ABSTRACT SYNTAX, values, and 
stores (Chapter 2). The state of an abstract machine undergoes transitions 
that are described by an OPERATIONAL SEMANTICS. 


ABSTRACT SYNTAX The underlying tree structure of a program’s source code. It is 
“abstract” in part because it abstracts away from such details as whether 
source code is written using round brackets and square brackets or whether 
it is written using semicolons and curly braces. Abstract syntax expresses 
the important truth about a program. Compare it with CONCRETE SYNTAX. 


Basis A basis comprises all the information available about a particular set of 
names. In Impcore, a basis is a pair of environments (¢,€). A basis pro- 
vides the context used to evaluate a definition, and evaluating a definition 
typically extends or alters the current basis. The basis available at startup is 
called the INITIAL BASIS. 
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What ts syntactic sugar and who benefits? 


Syntactic sugar is a means of defining syntax in terms of other syntax, without 
any operational semantics. Some examples appear in the text: C’s do.. while 
and C’s for loop can be defined as syntactic sugar for various combinations of 
while and begin (page 66). Such syntactic sugar can benefit programmers, im- 
plementors, designers, theorists, and other tool builders. 


Programmers benefit most from syntactic sugar when they don't know it’s there. 
Syntactic sugar is defined by translation, which is not easy to think about—if ev- 
ery time you want to use a do-while you first have to mentally translate it into 
something else, that’s not an aid; it’s a stumbling block. 


Implementors can benefit from syntactic sugar. If you implement a desugaring 
transformation on your syntax, then without any other change to your compiler 
or interpreter, you have a new language feature (Exercise 34). But as soon as 
your implementation gets serious—say you want to check types, as in Chapter 6, 
or you want to provide source-level-debugging—the syntactic sugar is not so use- 
ful, because you need to report errors or state in terms of the syntax the user 
wrote originally, not the desugared form. 


Language designers and theorists benefit the most from syntactic sugar. For 
example, let’s say you've completed Exercise 29: you’ve proven that Impcore 
can be evaluated on a stack. Now you want to add do-while, for, while*, or 
some other shiny new syntactic form. If the new form is just sugar—that is, 
if it is defined by translation into the original syntax, which you used in your 
proof—then you know the new, extended Impcore can still be evaluated on a 
stack. You don’t have to consider any new cases in your proof, and you don’t 
have to revisit any cases that you’ve already proven. This scenario describes a 
very effective use of syntactic sugar: a careful language designer benefits from 
small language, which is easy to prove things about, but the users benefit from 
a larger language, which is more attractive and makes it easier to say things 
idiomatically. Using syntactic sugar, a designer can have both. 


I have assumed that new syntactic sugar can be created only by a language de- 
signer or implementor. This assumption holds for most languages, including 
C and Impcore. the vast majority of other languages. But using Lisp, Scheme, 
and related languages, new syntactic sugar can be created by ordinary program- 
mers. This capability gives programmers many of the same powers as language 
designers (Section 2.14.4, page 171). 


BIG-STEP SEMANTICS A species of OPERATIONAL SEMANTICS in which each JUDG- 


MENT FORM expresses, in one step, the evaluation of syntax to produce a 
result. For example, a judgment (e,€,¢, p) |) (v,&,, p) shows how an ex- 
pression is evaluated to produce a value, or a judgment (d,€,¢) — (&', d’) 
shows how a definition is evaluated to produce a new ENVIRONMENT. Big- 
step semantics is well aligned with the way we think about programs. Com- 
pare it with SMALL-STEP SEMANTICS. 


COMPILER A language implementation that works by translating syntax into ma- 


chine code. The machine code may be for a real hardware machine made 
by a manufacturer like Intel or ARM, in which case the compiler is called a 
native-code compiler. Or the machine code may be for a virtual machine like 
the Java Virtual Machine or the Squeak virtual machine. 


CONCRETE SYNTAX The means by which a program’s source code is written, as a se- 
quence of characters or tokens. Concrete syntax specifies such details as what 
shape of brackets to use and where to use commas or semicolons. Concrete 
syntax is what we use when presenting a program to a computer or talking 
about programs with other people. Compare it with ABSTRACT SYNTAX. 


DEFINITIONAL INTERPRETER A language implementation that is intended to im- 
plement the language’s theory “directly,” or that is otherwise intended to il- 
lustrate a language’s theory. Almost sure to include a PARSER and EVALUA- 
TOR. All the interpreters in this book are definitional. 


ENVIRONMENT An mapping that stores information about names. For example, 
in Impcore, the environment € stores the value of each global variable. 
In old-school COMPILERS, an environment may be referred to as a SYMBOL 
TABLE. 


EVALUATION What a pointy-headed theorist talks about instead of “running code.” 


EVALUATOR A part of a language implementation that evaluates code directly. 
In this book, the evaluators evaluate ABSTRACT SYNTAX, but an evaluator 
may also evaluate intermediate code, virtual-machine code, or even machine 
code. 


EXPRESSION-ORIENTED LANGUAGE A programming language in which conditional 
constructs, control-flow constructs, and assignments, like if, while, begin, 
and set, are expressions, not statements—and evaluating each produces a 
value. Not usually associated with PROCEDURAL PROGRAMMING. 


GRAMMAR A set of formal rules that enumerates all the SYNTACTIC FORMS in each 
SYNTACTIC CATEGORY. A grammar produces the set of all programs that are 
grammatically well formed. A grammar can be designed to support a simple 
decision procedure that tells if a particular utterance was produced by the 
grammar, and if so, how. Such a decision procedure is embodied in a PARSER. 


INITIAL BASIS The BASIS used when first evaluating a user’s code. The initial basis 
contains all the PRIMITIVE FUNCTIONS and PREDEFINED FUNCTIONS. 


JUDGMENT A claim in a formal system of proof. In programming languages, 
a judgment often describes the evaluation of some syntactic form; for ex- 
ample, ((+ 22),&,¢,p) 4 (4, €, ¢, p) describes the evaluation of a function 
application. (Judgments about types are introduced in Chapter 6.) 


JUDGMENT FORM A template for creating JUDGMENTS. For example, the form of 
the evaluation judgment for Impcore is (e,£,¢,p) 4) (v,€', ¢, p’). Ajudg- 
ment form is transformed into to aJUDGMENT by substituting ABSTRACT SYN- 
TAX, values, ENVIRONMENTS, or other entities for its METAVARIABLES. 


METATHEORETIC PROOF A proof of a fact that is true of all valid derivations. Nor- 
mally proceeds by STRUCTURAL INDUCTION on derivations. 


METATHEORY Theorems about proofs. More broadly, mathematical tools for 
showing properties that are true for the execution of any program. Example 
properties might be that evaluating an expression never introduces a new 
global variable, or that Impcore can be evaluated on a stack, or that a secure 
language does not leak information. Compare it with THEORY. 
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METAVARIABLE A variable that stands for something used in a JUDGMENT FORM or 
elsewhere in a THEORY. Metavariables used in this book include 


e for an expression 

d for a definition 

x for a program variable 
v for a value 

p for an ENVIRONMENT 
o for a store (Chapter 2) 


The name of a metavariable tells a reader what kind of thing it stands for, but 
unfortunately, no two authors agree on names. Many authors, like Harper 
(2012), use a mix of Greek and Roman letters, but both Pierce (2002) and 
Cardelli (1989) use only Roman letters. 


NATURAL DEDUCTION A style of proof which is expressed using INFERENCE RULES 
with JUDGMENTS in the premises and conclusion. (In mathematical logic, 
these judgments would be called “propositions.”) This is the style of our BIG- 
STEP SEMANTICS; it supposedly accords with a “natural” way of reasoning. 
Natural deduction is associated with the mathematician Gerhard Gentzen. 


OPERATIONAL SEMANTICS A precise way of describing the evaluation of a pro- 
gram. Usually comprises PROOF RULES for JUDGMENTS about program eval- 
uation. The operational semantics gives enough information to write an 
EVALUATOR for a language. Varieties in this book include BIG-STEP SEMAN- 
TICS and SMALL-STEP SEMANTICS. 


PARSER The part ofa language’s implementation that translates CONCRETE SYNTAX 
to ABSTRACT SYNTAX. (A parser may also translate concrete syntax directly 
to intermediate code.) 


PARSING The process of transforming CONCRETE SYNTAX into ABSTRACT SYNTAX. 
More generally, the process of recognizing concrete syntax. (Some compil- 
ers and interpreters skip abstract syntax and instead generate code directly 
in the PARSER.) 


PREDEFINED FUNCTION A function that is available to every program written in a 
language, because by the time a user’s code is examined, the function's defi- 
nition has already been evaluated. Like the mod function in Impcore. A pre- 
defined function is not part ofits language; it can be defined using PRIMITIVE 
FUNCTIONS. 


PRIMITIVE FUNCTION A function that is built into a language or its implementa- 
tion, like the + function in Impcore. A primitive function typically cannot be 
defined using the other parts of its language, so it is considered a sort of a 
part of its language. 


PROCEDURAL PROGRAMMING A style in which programs are built by composing 
side-effecting SYNTACTIC FORMS in sequence. The forms typically produce 
no values and are called commands or statements. They are usually grouped 
into procedures. Procedural programs operate primarily on mutable data, and 
they tend to manipulate one machine word at a time. Impcore’s only data 
type, the machine integer, does fit in one word, but because it is immutable, 
Impcore is not a very good example of a procedural programming language. 


READ-EVAL-PRINT LOOP An interactive mechanism by which a programmer can 
run code. A definition or an extended definition is first read from standard 


input; then it is evaluated and its result is printed. And then the implemen- 
tation loops, waiting for the next definition. A read-eval-print loop enables 
a programmer to easily use or explore any function or variable. Alternatives 
that don’t support interactive exploration include command-line batch de- 
velopment, where a programmer uses operating-system commands to com- 
pile and run code, and app development, where code is developed and pack- 
aged on one platform and then shipped to run on another platform. 


SMALL-STEP SEMANTICS A species of OPERATIONAL SEMANTICS in which each 
JUDGMENT FORM expresses the smallest possible increment of computation. 
Such a semantics exposes the intermediate steps of the computation. An ex- 
ample appears in Chapter 3. Small-step semantics can express more kinds 
of program behaviors than BIG-STEP SEMANTICS, and the METATHEORETIC 
proof techniques used with small-step semantics tend to be simpler. 


SYMBOL TABLE A compiler writer's word for ENVIRONMENT. 


SYNTACTIC CATEGORY A group of SYNTACTIC FORMS that are grammatically inter- 
changeable. Examples of common syntactic categories include expressions, 
definitions, statements, and types. 


SYNTACTIC FORM A template for creating a phrase in a programming language, 
like (set xe). 


SYNTACTIC SUGAR A means of extending CONCRETE SYNTAX without changing AB- 
STRACT SYNTAX. Syntactic sugar is concrete syntax that is translated into ex- 
isting abstract syntax. Syntactic sugar can appear in a program, but it doesn’t 
make it to a theory or an EVALUATOR. Syntactic sugar can be used to add new 
loop forms to Impcore, for example (Section 1.8, page 66). 


THEORY Theorems about programs. More broadly, mathematical tools that spec- 
ify meaning and behavior of programs. Theory can be used to prove facts 
about individual programs and to specify an EVALUATOR or type checker. 
In this book, the theory of a language is its operational semantics plus, in 
Chapters 6 to 9, its type system. A language’s theory may be used to create a 
DEFINITIONAL INTERPRETER. Compare it with METATHEORY. 


1.9.2. Further reading 


Literate programming was invented by Knuth (1984); Noweb is described by Ram- 
sey (1994). 

The term “basis” is taken from the Definition of Standard ML (Milner et al. 
1997), where it refers to a collection of environments binding not only values but 
types, “signatures,” and other entities. 

Operational semantics got a big boost from Plotkin (1981), who describes a style 
of operational semantics that is better suited to proving properties of programs 
than the natural-deduction style that we use. The natural-deduction style was in- 
troduced by Kahn (1987); it is better suited to specifying evaluators. 

The notations used to describe grammars and semantics aren't standardized: 
the ideas are universal, but details vary. Common variations are ably described by 
Steele (2017), who also explains why the variations are mostly harmless. 

The first extensible printer for C programs that I know of was created by Ken 
Thompson; his implementation appeared in Ninth Edition Research Unix. Another 
implementation can be found in Chapter 14 of Hanson (1996). 
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Table 1.10: Synopsis of all the exercises, with most relevant sections 


Exercises Section Notes 


1to5 1.2 Writing Impcore syntax; simple functions that could use 
loops or recursion. 

6to8 1.2 Simple functions that demand recursion; functions that ma- 
nipulate decimal or binary representations. 

1.3 Syntactic structure and syntactic categories. 

10and11 1.4,1.5 Reading and writing judgments of operational semantics. 

12 to 14 1.7 Using operational semantics to prove facts about the evalu- 
ation of particular expressions. 

15 to 17 1.5 Writing new rules of operational semantics, for new features 
or for features not specified in the chapter. 

18 to 21 1.5 Writing new proof systems for new forms of judgment. 

22 to 27 Le Using metatheory to prove facts about all expressions. 

28and29 1.6,1.7 Using metatheory to prove facts about the implementation. 

30 to 32 1.6 Implementing new semantics for variables. 

33and34 1.6,1.8 Extend the interpreter with a new primitive or new syntax. 

35and 36 1.6 Improving the performance or error behavior of the inter- 
preter. 


A nice example of metatheory can be found in the Singularity project, which 
uses metatheory to guarantee the behavior of its device drivers (Hunt and Larus 
2007). 


1.10 EXERCISES 


If you read this book without doing any of the exercises, you'll miss most of what 
it has to offer. But don’t try to do all the exercises; you'll die of overwork. Choose 
your exercises well and you'll have a great experience. 

To help you find exercises, I’ve organized them by the skill they demand. 
In each chapter, you'll find a table of exercises that lists each group of exercises 
along with the skills they develop and the reading that is most necessary. Skills 
often include programming in a bridge language, working with a semantics, and 
modifying an interpreter—but there are others as well. In this chapter, the skills 
are listed in Table 1.10. 

Each chapter’s exercises are preceded by highlights. The highlights list exercises 
that are my personal favorites, or that I think are the best, or that I often assign 
to my students. And each chapter’s exercises begin with questions that support 
retrieval practice. These very short questions will help you keep the essential ideas 
at the surface of your mind, so you can do the exercises fluently. And if you are a 
student in a university course, they may help you study for exams. 

The highlights of this chapter’s exercises are as follows: 


* Of all the exercises on programming with numbers, my favorite is “convert 
decimal to binary” (Exercise 8 on page 76). The exercise has a clean, minimal 
solution, but to find it, you have to develop some insight into the inductive 
structure of numerals. If you have trouble, start with Exercise 7 on page 75. 


* You can do a little language design: What if variables didn’t have to be de- 
clared before use? (Exercise 16 on page 80) 


* You should write at least one derivation (Exercise 12 on page 77). To start rea- 
soning about derivations, follow up with Exercise 13 or 23 on pages 77 or 83. 


* You can do some metatheory. The very best of the metatheoretic exercises 
are Exercises 25 and 29 (pages 83 and 85). You may have to work up to 
them, but if you tackle either, or better yet both, you will understand which 
rules of the operational semantics are boring and straightforward and which 
rules have interesting and important consequences. Exercises 24 and 27 on 
pages 83 and 84 are significantly easier but also worthwhile. 


* To get some practice with the interpreter, add local variables to Impcore (Ex- 
ercise 30). It will help you think about the connection between semantics and 
implementation. 


1.10.1 Retrieval practice and other short questions 


Hoo Ow > 


28 Re op 


9° 


What’s the difference between function - and function negated? 
What does check-expect do? 

What is the value of the global variable it? 

What is the difference between concrete syntax and abstract syntax? 


An example on page 28 shows an example expression along with its abstract- 
syntax tree. The expression shown in the example uses the syntactic forms 
SET, APPLY, VAR, and LITERAL. What syntactic forms are used in the expression 
(if (< x 0) (negated x) x)? 


What syntactic forms are used in the expression (* (+ x y) (- x y))? 
What do the metavariables e and d stand for? 
What does the metavariable x stand for? 


When you evaluate (print 4), why does the interpreter print 44? What should 
you evaluate instead? 


Which Greek letter holds the values of all the global variables? 
Which Greek letter holds the values of all of a function’s formal parameters? 


What does p{x +> v} stand for? 


. How should you pronounce p{x +> vu}? 


What aspect of the implementation does (e, €, ¢, p) 4) (v, €’, d, p’) stand for? 


freee 
What is being claimed by a rule of the form at where each J is some 


kind of judgment? 


1.10.2 Simple functions using loops or recursion 


Some of the exercises in these first three sections are adapted from Kamin (1990, 
Chapter 1), with permission. 
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1. Understanding scope, from C to Impcore. The scope rules of Impcore are iden- 


tical to that of C. Consider this C program: 
74. (mystery.c 74) = 
int x; 


void R(int y) £¢ 


X= Va 


void Q(int x) £¢ 
R(x + 1); 
printf("%d\n", x); 


3 

void main(void) £¢ 
X = 2; 
Q(4); 


printf("%d\n", x); 


(a) For each occurrence of x in the C program, identify whether the occur- 
rence refers to a global variable or a formal parameter. 


(b) Say what the C program prints. 


(c) Write, in Impcore, a sequence of four definitions that correspond to the 
C program. Instead of printf, call printin. 


. Sums of consecutive integers. Define a function sigma satisfying the equation 


(sigmam n) = m+(m+1)+---+7. The right-hand side is the sum of 
the elements of the set {7 | m <i < n}. 


. Exponential and logarithm. Define functions exp and log. When base b and 


exponent n are nonnegative, (exp bn) = b”, and when b > landm > 0, 
(log b m) is the smallest integer n such that b”+! > m. Oninputs that don’t 
satisfy the preconditions, your implementation may do anything you like— 
even fail to terminate. 


. The nth Fibonacci number. Define a function fib such that (fib 7) is the nth 


Fibonacci number. The Fibonacci numbers are a sequence of numbers de- 
fined by these laws: 


(fib 0) =0 


(fib1) =1 
(fib n) = (fib (-n1)) + (fib (-n2)) whenn>1 


. Prime-number functions. Define functions prime?, nthprime, sumprimes, and 


relprime? meeting these specifications: 


(prime? n) is nonzero (“true”) if n is prime and 0 (“false”) otherwise. 
(nthprime 7) isthe nth prime number. Consider 2 to be the first prime 

number, so (nthprime 1) = 2, so (nthprime 2) = 3, andso on. 
(sumprimes 7) is the sum of the first n primes. 


(relprime? m n) is nonzero (“true”) if m and are relatively prime— 
that is, their only common divisor is 1—and zero (“false”) other- 
wise. 


Functions prime? and sumprimes expect nonnegative integers. Functions 
nthprime and relprime? expect positive integers. 


1.10.3 A simple recursive function 


6. Binomial coefficients without arithmetic overflow. Define a function choose 
such that (choose n &) is the number of ways that & distinct items can be 
chosen from a collection of n items. Assume that n and k are nonnegative in- 


; : . oe 1.10 
tegers. The value (choose n k) is called a binomial coefficient, and itis usually : ; 
itten (" bedefinedas—-"_. butthis definiti t : EMO 
written (3 Itcan be defined as kl(n—byv Dutthis definition presents compu 
tational problems: even for modest values of n, computing n! can overflow 75 


machine arithmetic. Instead, use these identities: 


when n > 0, 
when n > 0, 
m1) 4 (R71) whenn > Oandk > 0. 


—— 
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These identities guarantee that if the answer is small enough to fit in a ma- 


chine word, then the results of all of the intermediate computations are also 
small enough to fit in a machine word. 


1.10.4 Working with decimal and binary representations 


7. Properties of decimal representations. In this exercise, you write functions that 
take numbers apart and look at properties of their decimal digits. You'll 
need to understand how to define decimal representations inductively, as 
described in Exercise 18 below. 


(a) Write a function given-positive-all-fours?, which when given a 
positive number, returns 1 if its decimal representation is all fours and 
0 otherwise. 


75a. (exercise transcripts 75a) = 75¢ > 
-> (given-positive-all-fours? 4) 
1 
-> (given-positive-all-fours? 44444) 
1 
-> (given-positive-all-fours? 44443) 
0 


(b) Write a function all-fours?, which when given any number, returns 
1if its decimal representation is all fours and 0 otherwise. You could 
define a function like this: 


75b. (unsatisfying answer 75b)= 
(define all-fours? (n) 


(if (> n 0) (given-positive-all-fours? n) 0)) 


But that’s unsatisfying; instead, define just one function all-fours?, 
which you could then use in place of given-positive-all-fours?. 


75¢e. (exercise transcripts 75a) += 75a 76ab 
-> (all-fours? 0) 
0 
-> (all-fours? -4) 
0 
-> (all-fours? 4) 
1 
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(c) Define a function all-one-digit?, which when given a number, re- 
turns 1 if the decimal representation of that number uses just one of 
the ten digits, and zero otherwise. 
76a. (exercise transcripts 75a) += <75¢ 76b> 

-> (all-one-digit? 0) 

1 

-> (all-one-digit? -4) 

1 

-> (all-one-digit? 44443) 
0 

-> (all-one-digit? 33) 

1 


(d) Define a function increasing-digits?, which when given a number, 
returns 1 if in the decimal representation of that number, the digits are 
strictly increasing, and returns zero otherwise. 
76b. (exercise transcripts 75a) += 76a 

-> (increasing-digits? 1) 

1 

-> (increasing-digits? 1123) 
0 

-> (increasing-digits? 12435) 
0 

-> (increasing-digits? 489) 
1 


If you feel bold, try Exercise 6 in Chapter 2 (page 179). 


8. Decimal-to-binary conversion. Define a function binary such that (binary m) 
is the number whose decimal representation looks like the binary represen- 
tation of m. For example (binary 12) = 1100, since 11002 = 1219. An ideal 
implementation of binary will work on any integer input, including negative 
ones. For example, (binary -5) = —101. 


This exercise, like the previous one, will be easier if you can define decimal 
and binary representations inductively, as described in Exercise 18 below. 


1.10.5 Understanding syntactic structure 


9. Syntactic categories in another language. Here’s a discussion problem: Pick 
your favorite programming language and identify the syntactic categories. 


* What syntactic categories are there? 


* How are the different syntactic categories related? In particular, when 
can a phrase in one syntactic category be a direct part of a phrase in 
another (or the same) syntactic category? 


* Do all the phrases in each individual syntactic category share a similar 
job? What is that job? 


* Which syntactic categories do you have to know about to understand 
how the language is structured? Which categories are details that ap- 
ply only to one corner of the language, and aren't important for overall 
understanding? 


(The question continues on the next page.) 


In Impcore, these questions might be answered as follows: 


* The syntactic categories of Impcore are definitions and expressions. 


+ Adefinition may contain an expression, and an expression may contain 
another expression, but an expression may not contain a definition. 


+ In Impcore, the job of an expression is to be evaluated to produce a 
value. The job of a definition is to introduce a new name into an envi- 
ronment. 


1.10.6 The language of operational semantics 


10. 


11. 


Understanding what judgments mean. Take each of the following formal state- 
ments and restate it using informal English. 

(a) Either x € domporz € domé. 

(b) If x € dom, then (e, €, ¢, p) |) (0, €’, d, p’). 

(c) (,€, 6,0) 4 (v, 6, op’). 

(d) (e,€,9,p) ¥ (v,&, 6, 2). 

(e) If (e1,€,,) Ub (v1, &1, 6, pr) and (e2,€,,p) 4} (v2, &1, ¢, p1), then 


U1 = V2. 


Translating English into formal judgments. Take each of the following informal 
statements and restate it using the formalism of operational semantics. 


(a) Expression e can be evaluated successfully even if global variable x is 
not defined. 


(b) The result of evaluating e doesn’t depend on the value of global vari- 
able x. 


(c) Evaluating e doesn’t change the values of any global variables. 
(d) Evaluating e does not define any new global variables. 


(e) Unless function prime? is defined, expression e cannot evaluate suc- 
cessfully. 


(f) The evaluation of e terminates and the result is zero. 


(g) Ifthe evaluation of e terminates, the result is zero. 


1.10.7 Operational semantics: Facts about particular expressions 


To help you with the operational-semantics exercises, the rules of Impcore’s oper- 
ational semantics are summarized in Figures 1.11 and 1.12. 


12. 


13. 


Proof of the result of evaluation. Use the operational semantics to prove that if 
you evaluate (begin (set x 3) x) in an environment where p(x) = 99, then 
the result of the evaluation is 3. In your proof, use a formal derivation tree 
like the example on page 57. 


Proof of equivalence of two expressions. Show that expression (if x x @) is ob- 
servationally equivalent to just x. That is, show that the two expressions can 
be interchanged in any program, and if we run both variants, we won't be 
able to observe any difference in behavior. 


$1.10 
Exercises 


77 


(LITERAL) 


(LITERAL(v), €, 9, p) I (v,&, , p) 


x € domp 


(ar(2), €4,p) 4 (pe). 4,0) ‘ee 

mae oF Viehes p) MeEOReN aR) 

ee REETN ERE yey PonmaAssON 
x¢domp x€domg€ _ (e,€,¢,p) 4 (v,€',¢, 0’) eesuheaay 


(sET(a,€),€,,p) } (v, €/{a + v}, 6, p') 


(e1,€, ¢, p) 4 ig € 5 Q, p') U1 a 0 (e2,€, d, p’) ay (v2, €", ¢, p") 
(IF(e1, €2, €3), €; d, p) a (v2, ie d, i) 


(IFTRUE) 


(e1, € >, p) \ (v1, &', d, p’) U1= 0 (e3,€',¢, p') 1 (v3, &", d, p"’) 
(IF(€1, €2, €3), g, d, p) a (v3, ae ¢, i) 


(IFFALSE) 


(1, €, d, p) a (v1, €', d, 0’) U1 #0 
(e2, eS é, p’) 1 (v2, Gi, ?, p”’) (WHILE(€1, €2), &", d, p"") \ (v3, aie d, pl") 
(WHILE(€1, €2), g, ¢, p) a (v3, Eu d, re 


(WHILEITERATE) 


(e1,€,¢, p) a (v1, €', >, p’) U1 =0 
(WHILE(€;, €2), g, ¢, p) a (0, &, Q, p’) 


(WHILEEND) 


(EMPTYBEGIN) 


(BEGIN(), €, , p) 4) (0, €, , p) 


(€1, £0, 9, Po) al (v1, &1, 9, Pi) 
(€2,&1, Q, Pi) al (v2, &2, >, p2) 
(€n,€n—1, , Pn—1) a, (Un, En; @, Pn) 
(BEGIN (€1, CQ, ++ +5 Gin) £05 , Po) al (Un; En; ¢, Pn) 


o(f) = USER((11, at iL) e) 
@1,.--,Xy all distinct 


(e1, £0, d, Po) al (v1, &1, d, 1) 


(BEGIN) 


(Ons En—1) ¢, Pn-1) a (Un, ay ¢, Pn) 
Ven eas d, {@1 FUL, +++, hn b> Un }) 1 (v, &, Q, p!) 
(APPLY(f, Ely--+5 CarS0s ¢, Po) a (u, eS d, Pn) 


(APPLYUSER) 


Figure 1.11: Summary of operational semantics (expressions) 


(656 Oth) 4 (6, 6,0") 


Wat (e,€),€,6) > (far v},9) prgmncrs 
Y1,..-,%y all distinct 
(DEFINE(f, (@1,.--,2n),e),§, 6) > (€, d{ f H USER((21,..., an), e)}) 
(DEFINEFUNCTION) 
(e, & d, {}) al (v, &5 Q, p') (EVALEXP) 


(ExP(e),£,) — (f'{it > v}, ¢) 


Figure 1.12: Summary of operational semantics (definitions) 


(a) Use the operational semantics to show that if there exist environments 
€, d, and p (and €’, p’, €”, and p”) such that 


(IF(VAR(x), VAR(x), LITERAL(()),€, 0, 0) 4) (v1, €', @ p’) 


and 
(vAR(x), €, 9, p) 4 (v2,€", 6, 2") 
then vy = V2. 


(b) Now use the operational semantics to show that there exist environ- 
ments €, ¢, p, &’, and p’ anda value v, such that 


(IF(VAR(x), VAR(x), LITERAL(()),€,, 0) 4) (v1, €', @ p’) 


if and only if there exist environments €, ¢, p, €”, and p” anda value v2 
such that 


(var(x), €, 0, p) I (v2,€", ¢, p”). 


Give necessary and sufficient conditions on the environments ¢, ¢, 
and p such that both expressions evaluate successfully. 


(c) Finally, extend your proof in the first part to show that not only are the 
results equal, but the final environments are also equal. 


14. Proof that begin can be eliminated. Impcore can be simplified by eliminating 
the begin expression—every begin can be replaced with a combination of 
function calls. For this problem, assume that @ binds the function second 
according to the following definition: 


(define second (x y) y) 


I claim that if e; and e2 are arbitrary expressions, you can always write 
(second e; e2) instead of (begin e; e2). 


(a) Using evaluation judgments, take the claim “you can always write 
(second €; €2) instead of (begin e; e2)” and restate the claim in pre- 
cise, formal language. 

Hint: The claim is related to the claims in Exercise 13. 

(b) Using operational semantics, prove the claim. 

(c) Define a translation for (begin e, -- - €,,) such that the translated code 
behaves exactly the same as the original code, but in the result of the 
translation, every remaining begin has exactly two subexpressions. 
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15. 


16. 


For example, you might translate 
(begin e1 e2 e3) 

into 
(begin e1 (begin e2 e3)) 


If you apply the translation recursively, then replace every begin with a call 
to second, you can eliminate begin entirely. 


1.10.8 Operational semantics: Writing new rules 


Operational semantics of a for loop. Give operational semantics for a C-like 
FOR(e1, €2, €3,€4). Like a while expression, a for expression is evaluated 
for its side effects, so the value it returns is unimportant. Choose whatever 
result value you like. 


Extending Impcore to allow references to unbound variables. In Impcore, it is an 
error to refer to a variable that is not bound in any environment. In Awk, the 
first use of such a variable (either for its value or as the target of an assign- 
ment) implicitly creates a new global variable with value 0. In Icon, the rule 
is similar, except the implicitly created variable is a local variable, whose 
scope is the entire procedure in which the assignment appears. 


(a) Change the rules of Impcore as needed, and add as many new rules as 
needed, to give Impcore Awk-like semantics for unbound variables. 


(b) Change the rules of Impcore as needed, and add as many new rules as 
needed, to give Impcore Icon-like semantics for unbound variables.° 


(c) Which of the two changes do you prefer, and why? 


(d) Create a program that can distinguish standard Impcore semantics 
from the Awk-like and Icon-like extensions described above. In partic- 
ular, create a source file awk-icon.imp containing a sequence of defi- 
nitions with the following properties: 


+ Every definition in the sequence is syntactically valid Impcore. 

+ If you present the sequence of definitions to a standard Impcore 
interpreter, the result is a checked run-time error. 

* If you present the sequence of definitions to an Impcore inter- 
preter that has been extended with the Awk-like semantics, the last 
thing the interpreter does is print 1. 

* If you present the sequence of definitions to an Impcore inter- 
preter that has been extended with the Icon-like semantics, the 
last thing the interpreter does is print 0. 


17. Formal semantics of unit tests. The semantics of extended definitions hasn't 


been formalized. But some of the pieces can be formalized easily enough: 


(a) Design a judgment form to express the idea that “a check-expect test 
succeeds.” Your judgment form should include environments ¢ and €. 
Write a proof rule for the new judgment form. 


(b) Design a judgment form to express the idea that “a check-expect test 
fails.’ Write a proof rule for it. 


®Impcore has top-level expressions, and Icon does not. For purposes of this problem, assume that 
every top-level expression is evaluated in its own, anonymous procedure. 


(c) Design a judgment form to express the idea that “a check-error test 
fails.” Write a proof rule for it. 


The success of a check-error test is another matter entirely: it requires more 
than just a single rule. For that, look at Exercise 21. 


1.10.9 Operational semantics: New proof systems 


18. 


19. 


Meanings of numerals. A numeral is what we use to write numbers. Like an 
Impcore expression or definition, a numeral is syntax. Decimal numerals 
can be defined using a grammar: a decimal numeral No is composed of 
decimal digits d: 


d :=0|1/2|3|4|5|6|7|8|9 
N10 := d|Niod 


In informal English, we might say that a decimal numeral is either a single 
decimal digit, or itis a (smaller) decimal numeral followed by a decimal digit. 


The meaning of a numeral is a number—a numeral is syntax, and a number 
is a value. The numerals above are written in typewriter font; the numbers 
below are written in ordinary math font. The meaning of a decimal numeral 
No can be specified by a function D. Function D is specified by a set of re- 
cursion equations, each of the form D[Njo] = e, where e is a mathematical 
formula. (The [-- -] symbols are called “Oxford brackets,’ and they are used 
to wrap syntax.) Each equation corresponds to a syntactic form: one for each 
decimal digit and one for the form in which a numeral is followed by a digit. 


D[o] =0 D[e] =2 D[4] =4 D[6] =6 D[s] =8 
P[1] =1 D[3] =3 D[5] =5 D[7] =7 D[9] =9 
D[Niod] = 10- DIMi0] + Pld] 


(The expression 10 - D[.Nio] means “10 times D[.Ni9]”; as described in Ap- 
pendix B, this book uses the x symbol only for type theory.) In this exercise, 
you write a similar specification for binary numerals. 


(a) Define precisely what is a binary digit. 
(b) Write an inductive definition of binary numerals. 


(c) Using a meaning function B, write recursion equations that define the 
meaning of a binary numeral. 


Proof systems for program analysis: having set. Impcore is an imperative core 
because it uses side effects. Of these side effects, the most important is mu- 
tation, also known as assignment.’ In Impcore, assignment is implemented 
by set. In this exercise, you use proof theory to reason about a very simple 
property: whether an expression has set in it. Looking forward, in Exer- 
cise 25, you can see what you can prove if you know an expression doesn’t 
have a set. 


To see if an expression has set, you can just look at it. But that’s a plan for a 
person, not an algorithm for a computer or a set of rules for a proof. The idea 


’The other side effects are printing and use. 
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of “expression e has a set in it” can be made precise by introducing a judg- 


ment form| e has SET |, The judgment is defined by this proof system: 


SET ———_—_——- 
SET(x, e) has SET 


e1 has SET €2 has SET e3 has SET 


IF1 IF2 IF3 
IF(€1, €2, €3) has SET IF(€1, €2, €3) has SET IF(€1, €2, €3) has SET 


An imperative core 1 has SET €9 has SET 
WHILE1 WHILE2 
82 WHILE(€1, €2) has SET WHILE(€, €2) has SET 
e; has SET 
BEGIN ,t€ {1,...,n} 
BEGIN(€1,..., €n) has SET 
e; has SET 
APPLY ,t€ {1,...,n} 
APPLY(f,€1,..-.,@n) has SET 


The proof system has some notable properties: 


* There are no rules for variables or for literal values. And no wonder: 
variables and literal values are expressions that don't have set. 


* There’s no premise on the rule for SET. A set expression definitely has 
set, no matter what’s true about its subexpressions. 


« Any other expression has set if and only if one of its proper subexpres- 
sions has set. Expressing that idea requires a rule for each subexpres- 
sion. For IF and WHILE, the necessary rules can be written explicitly, 
but BEGIN and APPLY require rule schemas. The notation? € {1,...,n} 
means that a rule is repeated n times: once for each value of 2. 


Solve the following two problems: 


(a) Prove that the expression 


(while (> x 1) 
(if (= © (mod x 2)) 
(set x (/ x 2)) 
(set x (+ (* 3 x) 1)))) 


has set. 


(b) Show that having set isn’t the same as evaluating set. Give an exam- 
ple of an expression e such that e has SET, but you can guarantee that 
evaluating e never evaluates a set. 


20. Proof systems for program analysis: lacking set. When an expression has set, 
the proof system in the previous problem tells us. But if an expression doesn’t 
have set, that proof system tell us nothing! To know that expression doesn’t 
have set requires another proof system. Develop a proof system for yet 


another judgment form: |e hasn't SET|. Your proof system should derive 
“e hasn't SET” exactly when expression e doesn’t have a set in it. 


Your proof system’s structure should be related to the structure of the proof 
system for “e has SET.” The relationship is what a mathematician would call 
dual: 


21. 


* Where “e has SET” lacks proof rules, such as for literals and variables, 
“e hasn't SET” will have trivial proof rules with no premises. 


* Where “e has SET” has a trivial proof rule with no premises, such as for 
set, “e hasn't SET” will lack proof rules. (There’s no way you can prove 
that a set expression doesn’t have set.) 


+ Where ¢ has subexpressions, for “e has SET” it is sufficient to prove that 
any of e’s subexpressions has a set. But for “e hasn't SET” itis necessary 
to prove that all of e’s subexpressions have not got set. (This duality is 
an instance of DeMorgan’s Law.) 


Your proof system will be correct if every expression either has SET or it 
doesn’t (Exercise 22). 


Proof system for checked run-time errors. To show when a check-error test suc- 
ceeds, we need to be able to show when evaluation of an expression termi- 
nates with an error. Such a conclusion requires a pretty big proof system: 
not quite as big as the complete operational semantics of Impcore, but bigger 
than the proof systems for e has SET and e hasn’t SET in Exercises 19 and 20. 


(a) Design a judgment form to express the idea that evaluation of an ex- 
pression terminates with an error. Your form will need all the same 
environments as the form for evaluating an expression that produces a 
value. 


(b) Write a proof system for this judgment form. 


(c) Design a judgment form to express the idea that “a check-error test 
succeeds.” Using your proof system from part (b), write a proof rule for 
your new judgment form. 


(d) Ifarun-time error occurs during the evaluation of a check-expect test, 
that test is deemed to fail. To cover this possibility, write additional 
proof rules for the judgment that “a check-expect test fails.” 


1.10.10 Metatheory: Facts about derivations 


22. 


23. 


24. 


25. 


An expression either has SET or it doesn’t. Show that the two judgments in Ex- 
ercises 19 and 20 are mutually exclusive and cover all cases. That is, for any 
expression e, there is a valid derivation of exactly one of the two judgments 
e has SET and e€ hasn't SET. Try proof by induction on the syntactic structure 
of e. 


A WHILE expression evaluates to zero. Prove that the value of a WHILE expres- 
sion is always zero. That is, given any €, @, p, e1, and eg, if there exist a £’, p’, 
and v such that there is a derivation of (WHILE(€1, e2), €, 4, p) |) (v, €’, d, p’), 
then v = 0. Use structural induction on the derivation. 


Expression evaluation doesn’t add or remove global variables. Prove that the ex- 
ecution of an Impcore expression does not change the set of variables bound 
in the global environment. That is, prove that if (e,€,¢, p) |) (v,€’, ¢, p’), 
then dom € = dom €’. 


Program analysis and expression evaluation: does lacking SET guarantee un- 
changed variables? Is it true or false that evaluating an expression without a 
SET node does not change any environment? Use metatheory to justify your 
answer. To be sure you understand what it means to have a SET node, see 
Exercise 19. 
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26. 


27. 


28. 


Does evaluation guarantee defined variables? Section 1.7.3 on page 61 shows 
how to attempt a metatheoretic proof, and it examines the conjecture “if ex- 
pression e evaluates, all its variables are defined.” Section 1.7.3 addresses 
every rule except for WHILEITERATE and WHILEEND. 


(a) For derivations ending in WHILEITERATE, either prove the conjecture 
or show an expression whose evaluation is a counterexample. 


(b) For derivations ending in WHILEEND, either prove the conjecture or 
show an expression whose evaluation is a counterexample. 


(c) Explain in informal English what is going on with while loops—when, 
whether, and how do we know if a while loop’s variables are defined? 


Impcore is deterministic. Prove that Impcore is deterministic. That is, prove 
that for any e and any environments €, ¢, and p, there is at most one v such 


that (e, €,¢, p) |) (v, €', ¢, p’). 


You'll reason about two potentially different derivations, each describing 
its own evaluation of e. Think carefully about your induction hypothesis. 
For example, to prove that expression (begin €g x) evaluates to at most 
one v, what do you need to know about the evaluation of eg? 


1.10.11 Advanced metatheory: Facts about implementation 


Updating environments in place. In the judgment (e, £0, &, Po) 4) (v, En, ; Pn), 
the subscripts suggest that between the initial state (e€, &), 6, 9) and the final 
state (v,€,,, Pn) there are n steps of computation. A variable is evaluated 
in one step, an expression like (set x 3) in two steps, and so on. I conjec- 
ture that once a step is complete, the environments in its initial state can be 
discarded. As an example, here is a derivation D for (set x 3): 


£1 = £0 pi = po 
x ¢ dom po LE dom (3, £0, d, Po) al (3, €1, %, p1) &2 = €1 {x re 3} p2 = Pl ; 
((set x 3), &0, Q, po) a) (3, 2, Q, p2) 


Now D can be a subderivation in a larger derivation for (set y (set x 3)): 


D 
y€dompo ((set x3), £0, , po) | (3,€2,¢,p2) €3 =€2 p3=pe{yr 3} 
((set y (set x 3)), 0, 6, po) V (3, €3, , ps) 


In these derivations, each part of each state is given a name. For example, 
in the first derivation, the environment €|{x +> 3} is named £9. The sub- 
scripts on the metavariables may help you see that, for example, £9 and po 
are used multiple times, but that after judgment (3, £9, 4, Po) 4) (3, &1, ¢, px) 
is proved, only €, and p; are used thenceforth—environments £9 and pop are 
never used again. The transition from &, and p; to £2 and pg is similar, and 
so on. This observation suggests an optimization that is used in this chapter: 
where the derivation says something like £2 = €,{x +> 3}, the implementa- 
tion needn’t build a fresh environment €2. It can instead simply update a data 
structure: first the data structure holds €,, then after the update, it holds £5. 


Show that this optimization does not affect the semantics: 
(a) Prove that in any valid derivation, evaluation judgments can be totally 


ordered by their use of the global-variable environment. That is, the 
premises required to prove any judgment can be ordered in such a way 


that after the proof of every evaluation judgment, each of which takes 
the form (e;,&:,6,pi) (vi, 41, %, pit1), global-variable environ- 
ment €; is never used again and can be discarded. 

This metatheorem justifies using bindval(e->set.name, v, globals) 
to overwrite the globals environment when set is evaluated. 


(b) Show that uses of the formal-parameter environment cannot be totally 
ordered: Exhibit a valid derivation containing a judgment of the form 
(ei, 6,0, pi) | (vi, S41, &, P41), such that the next evaluation judg- $1.10 
ment has an initial state of the form (e, 41, ¢, p), where p is inde- Exercises 
pendent of p;41, and furthermore, some other evaluation judgment has 
an initial state that depends on p;+1. Formal-parameter environments 
cannot simply be mutated in place. Their optimization is the topic of 
the next exercise. 
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29. Keeping environments on a stack. Formal-parameter environments can be kept 
ona stack. To show this, you will imagine an implementation that uses an ex- 
plicit stack of environments. And write a semantics for it. You will imagine 
an implementation halfway between the operational semantics of this chap- 
ter and a stack machine that is described in Chapter 3. 


Your semantics will describe an abstract machine that will be almost identi- 
cal to the Impcore machine, except the last element of the state will be a non- 
empty stack of formal-parameter environments. A nonempty stack should be 
written as p:: 5, where S is a (possibly empty) stack of formal-parameter en- 
vironments. Each rule will affect only the top of the stack, so the judgment 
form will be (e, €,, p :: S) 4} (uv, €', d, p! :: S). 


(a) Rewrite the semantics of Impcore to use this new judgment form. En- 
sure that if it is necessary use some other environment and also to re- 
member p, that the new environment is pushed on top of the stack p::S. 


In eval, the implementation of every proof rule that ends in the judgment 
form (e,€,¢,p:: S) |) (v,&',¢, p’ :: S) can be implemented by popping p 
off the stack, doing some computation, and pushing p’ onto the stack. (It is 
possible that p’ = p.) The computation in the middle may include pushes, 
pops, and recursive calls to eval. And once p is popped off the stack, it is 
used only to make p’ and not in any other way—so it is safe to compute p’ by 
mutating p in place. 


(b) Prove that if p’ = p, then the only copy of p is the one on top of the 

stack. If p’ 4 p, then once p is popped off the stack, it is thrown away 
and never used again. In particular, no environment ever needs to be 
copied anywhere except on the stack; that is, every environment that 
might ever be needed is present on the stack. 
Use structural induction on a derivation of the evaluation judgment 
(e,€,¢,p:: 8S) \) (v,&',¢, p’ :: S). The base cases are the rules that 
have no evaluation judgments in the premises, such as the LITERAL or 
FORMALVAR rules. The induction steps are the rules that do have eval- 
uation judgments as premises, such as FORMALASSIGN. 


yy 


This lemma implies that the operation “pop p; push p"” can be replaced by the 
operation “mutate p in place to become p’.” In particular, p{x +> v} can be 
implemented by mutating an existing binding; building a new environment 
is not necessary. The mutation is safe only because the sole copy of p is on 
top of the stack. 
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This theorem justifies my implementation of bindval, as referred to in Sec- 
tion 1.6.3. The stack is the C call stack. 


1.10.12 Implementation: New semantics for variables 


30. 


31. 


32. 


Adding local variables to Impcore. Extend function definitions so that an Imp- 
core function may have local variables. That is, change the concrete and 
abstract syntax of definitions to: 


(define function-name (formals) [(locals locals) | expression) 
Userfun = (Namelist formals, Namelist locals, Exp body) 


where locals, having the same syntax as formals, names the function's local 
variables. The square brackets in “(locals locals) | ” means that the locals 
declaration can be omitted; when the concrete syntax has no locals decla- 
ration, the abstract syntax has an empty list of locals. 


If a local variable has the same name as a formal parameter, then in the body 
of the function, that name refers to the local variable. And before the body 
of the function is evaluated, each local variable must be initialized to zero. 


You will have to change the definitions of struct Userfun and function 
mkUserfun, as well as the relevant case in reduce_to_xdef in chunk S196a 
in Section G.2. But you will focus on the evaluator in eval.c. Make sure that 
after your changes, the interpreter still checks that the number of actual pa- 
rameters is correct. 


An example function that uses local variables appears in Figure 1.9 (page 67). 


Extending Impcore to work with unbound variables. Implement your solutions 
to Exercise 16. Use your implementation to test the code you write to distin- 
guish the new semantics. 


Passing parameters by reference. Change the Impcore interpreter to pass pa- 
rameters by reference instead of by value. For example, if a variable x is 
passed to a function f, function f can modify x by assigning to a formal pa- 
rameter. If a non-variable expression is passed as an argument to a func- 
tion, assignments to formal parameters should have no effect outside the 
function. (In particular, it should not be possible to change the value of an 
integer literal by assignment to a formal parameter.) 


To implement this change, change the return type of eval and fetchval to 
be Value*, and make Valuelists hold Value*s rather than Values. Type 
checking in your C compiler should help you find the other parts that need 
to change. No change in syntax is needed. 


Explore your implementation by writing a function that uses call by refer- 
ence. A good candidate is a function that wants to return multiple values, 
like a division function that wants to return both quotient and remainder. 
Then address these questions: 


(a) Is the bindval function in the environment interface still necessary? 


(b) How does call by reference affect the truth of the assertion (page 22): 
“no assignment to a formal parameter can ever change the value of a 
global variable”? 


(c) What are the advantages and disadvantages of reference parameters? 
Do you prefer Impcore with call by reference or call by value? If ar- 
rays were added to Impcore, as in Chapter 6, how would your answers 
change? 

Justify your answers, preferably using examples and scenarios. 


1.10.13 Extending the interpreter 


If you intend to do some of the interpreter exercises in Chapters 2 to 4, the exercises 
below will help you get started (as will Exercise 30 above). 


33. 


34. 


35. 


Adding a new primitive. Add the primitive read to the Impcore interpreter 
and the initial basis. Function read is executed for its side effect; it takes no 
arguments, reads a number from standard input, and returns the number. 


Adding new concrete syntax. Using syntactic sugar, extend Impcore with the 
looping constructs discussed in Section 1.8: 
(a) Implement the C-style do-while. 


(b) Implement while*, which allows you to code a loop that does multiple 
operations, without begin. 


(c) Implement the C-style for loop, described as FOR in Exercise 15. 
Emulate the code in Section G.7 on page $209 of the Supplement. 


Recovering lost file descriptors. The implementation of use in chunk (evaluate 
d->use, possibly mutating globals and functions $296c) leaks open file de- 
scriptors when files have bugs. Explain how you would fix the problem. 


1.10.14 Interpreter performance 


36. 


Profiling. Write an Impcore program that takes a long time to execute. Profile 
the interpreter. 


(a) Approximately what fraction of time is spent in linear search? Approx- 
imately how much faster might the interpreter run if you used search 
trees? What about hash tables? 


(b) Download code from Hanson (1996). and use it to implement names 
and environments. (The code can likely be found at its archival site, 
https: //www.cs.princeton.edu/software/cii.) How much speedup 
do you actually get? 


(c) What other “hot spots” can you find? What is the best way to make the 
interpreter run faster? 


An Impcore “program” is simply a sequence of definitions. 
p prog ply q 
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Scheme, S-expressions, and first-class functions 


Programming languages should be designed not by 
piling feature on top of feature, but by removing the 
weaknesses and restrictions that make additional 
features appear necessary. Scheme demonstrates that a 
very small number of rules for forming expressions, 
with no restrictions on how they are composed, 

suffice to form a practical and efficient programming 
language that is flexible enough to support most of 

the major programming paradigms in use today. 


Jonathan Rees and William Clinger (eds.), 
The Revised ® Report on the Algorithmic Language Scheme 


Scheme combines power and simplicity. Scheme is derived from Lisp, which John 
McCarthy developed—inspired in part by Alonzo Church’s work on the A-calculus— 
while exploring ideas about computability, recursive functions, and models of 
computation. McCarthy intended Lisp for computing with symbolic data he called 
S-expressions. S-expressions are based on lists, and the name “Lisp” was formed 
from “list processing.” Lisp programs can be concise and natural programs, and 
they often resemble mathematical definitions of the functions they compute. Lisp 
has been used heavily in artificial intelligence for over fifty years, and in 1971, 
McCarthy received ACM’s Turing Award for contributions to artificial intelligence. 

Lisp spawned many successor dialects, of which the most influential have been 
Common Lisp and Scheme. Common Lisp was designed to unify many of the di- 
alects in use in the 1980s; its rich programming environment has attracted many 
large software projects. Scheme was designed to be small, clean, and powerful; 
its power and simplicity have attracted many teachers and authors like me. 

Scheme was created by Guy Steele and Gerry Sussman, who introduced the 
main ideas in a classic series of MIT technical reports in the late 1970s, all bearing 
titles of the form “LAMBDA: The Ultimate (blank).” And Scheme may have been 
made famous by Abelson and Sussman (1985), who show off its ability to express 
many different programming-language ideas and to build programs in many dif- 
ferent styles. 

So what is Scheme? To answer such a question, set aside the syntax; the essence 
of a language lies in its values. If the essence of C is pointer arithmetic, the essence 
of Perl is regular expressions, and the essence of Fortran is arrays, the essence of 
Scheme is lists and functions.’ 


Today, any list of Scheme’s essential aspects would also include hygienic macros. But hygienic 
macros were developed relatively late, in the 1980s and 1990s, well after the other foundations of Scheme 
were laid down. And unlike those foundations, macros have not colonized other languages. In this book, 
macros, substitution, and hygiene are just barely touched on. 
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Lists come from original Lisp. Lists can contain other lists, so they can be used 
to build records and trees. Lists of key-value pairs can act as tables. Add numbers 
and symbols, and lists provide everything you need for symbolic computation. 

In addition to lists, Scheme provides first-class, higher-order, nested functions. 
Nested functions are created at run time by evaluating lambda expressions, which 
should dramatically change our thinking about programming and computation. 

Scheme was meant to be small, but full Scheme is still too big for this book. 
Instead, we use Scheme (pronounced “micro-Scheme’”), a distillation of Scheme’s 
essential features. In this book, “Scheme” refers to ideas that Scheme and wScheme 
share. “Full Scheme” and “Scheme” refer to the large and small languages, respec- 
tively. 


2.1 OVERVIEW OF {SCHEME AND THIS CHAPTER 


Scheme shares some central ideas with Impcore, which you know: 


* Scheme encourages interactive programming with functions. Scheme pro- 
grammers don’t “write a program’; they “define a function.” They don't “run 
a program”; they “evaluate an expression.” 


* Scheme has simple, regular syntax. It has no infix operators and therefore 
no operator precedence. 


pScheme goes beyond Impcore in five significant ways: 


+ puScheme makes it easy to define local variables, which are introduced and 
initialized by let expressions. 


* In addition to machine integers, Scheme provides Booleans values, sym- 
bols, functions, lists of values, and a species of record structure. 


* Instead of loops, Scheme programmers write recursive functions.” 


* pScheme’s functions, unlike Impcore’s functions, are values, which can be 
used in the same ways as any other value. In particular, functions can be 
passed as arguments to other functions and returned as results from other 
functions; they can also be assigned to variables and even stored in lists. Such 
functions are said to be first class. 


Functions that accept functions as arguments or return functions as results 
are called higher-order functions; functions that accept and return only non- 
functional values are called first-order functions. Only first-order functions 
are found in Impcore. 


« Anonymous, nested functions are defined by a new form of expression, the 
lambda expression. 


These language changes wind up changing our programming style: 


* Much as arrays, loops, and assignment statements lead to a procedural style 
of programming, S-expressions, recursive functions, and let binding lead to 
a new, applicative style of programming. 


? Although mathematicians have used recursion equations for centuries, computer scientists took a 
long time to recognize recursion as practical. Alan Perlis said that when some of the world’s leading 
computer scientists met in 1960 to design the language Algol 60, “We really did not understand the im- 
plications of recursion, or its value, ... McCarthy did, but the rest of us didn’t” (Wexelblat 1981, p. 160). 


1. Asymbol, number, or Boolean is 


Values Rules 

: a value. 
Ordinary S-expressions land 2 2. A list of values is a value. 
Fully general S-expressions 1, 2, and 4 3. A function is a value. 
Values ito 4. If vy and v2 are values, 


(cons v1 V2) produces a value. 


Figure 2.1: Summary of rules for jsScheme values 


* The ability to define first-class, nested functions leads to a powerful new pro- 
gramming technique: higher-order programming. 


The addition of nested functions, with the ability of one function to change an en- 
closing function’s variables, requires a change in the semantics: 


* InImpcore, environments map names to values, and assignment (set) is im- 
plemented by binding new values. In Scheme, environments map names 
to mutable locations, which contain values. Assignment is implemented by 
changing the contents of locations (Section 2.7.1). 


Details are found throughout the chapter, organized as follows: 


S-expressions and other values are formed according to four simple rules 
(Section 2.2). 


Recursion exemplifies applicative programming (Section 2.3). 


List elements are addressed by position; to enable us to refer to an element 
by its name, juScheme provides a record construct. Records in turn are used 
to represent trees (Section 2.4). 


Applicative code is clearly and succinctly specified by algebraic laws. Alge- 
braic laws are much easier to work with than operational semantics; we can 
prove facts about applicative code using just simple algebra (Section 2.5). 


Local names are introduced by let bindings (Section 2.6). 


First-class, nested functions are created by lambda expressions (Section 2.7). 
They support list processing (Section 2.8), code reuse via polymorphism (Sec- 
tion 2.9), and backtracking search via continuation passing (Section 2.10). 


pScheme’s run-time behavior is specified by an operational semantics (Sec- 
tion 2.11) and implemented by an interpreter (Section 2.12). 


Conveniences like record, short-circuit conditionals, and other conditional 
forms can be implemented as syntactic sugar. Making the sugar work cor- 
rectly requires attention to substitution and hygiene (Section 2.13). 


2.2 LANGUAGE I: VALUES, SYNTAX, AND INITIAL BASIS 


Scheme’s values include not only integers but also Booleans, functions, symbols, and 
lists of values, all of which are described below. The ones that can easily be written 
down—the ones that don’t involve functions—are called S-expressions, which is short 
for “symbolic expressions.” 


§2.2 
Language I: 
Values, syntax, 
and initial basis 
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Scheme’s least familiar sort of value is the symbol; a symbol is a value that is a 
name. To paraphrase Kelsey, Clinger, and Rees (1998), what matters about symbols 
is that two symbols are identical if and only if their names are spelled in the same 
way. That is, symbols behave like Name values from the Impcore interpreter. And 
like Names, symbols are often used to represent identifiers in programs. They are 
also used in the same way that enumeration literals are used in C, C++, or Java. 

The other forms of jScheme value are more familiar: numbers, Booleans, lists, 
and functions. They are described by three inductive rules, which are summarized 
in Figure 2.1 on the previous page: 


1. A symbol is a value, and so is a number. The Boolean values #t and #f are 
values; #t and #f, not 1 and 0, canonically represent truth and falsehood. 


Values defined by this rule are atomic: like atoms in the ancient Greek theory 
of matter, they have no observable internal structure and cannot be “taken 
apart.” Atomic values are also called atoms. 


2. If v1,...,Un are values, then that list of n values is also a value, and it is 
written (Vv, --: U,). Even when n = 0, the empty list, which is written (), 
is a value. And the empty list is considered to be an atom as well as a list. 


3. Every function is a value. 


Although rules 1 to 3 cover the common cases, Scheme provides one more form 
of value, which can be explained only by referring to zScheme’s cons primitive, 
which is described below. 

Values formed by rules 1 and 2 are ordinary S-expressions, usually called just 
“S-expressions.” Examples might include the following: 


3 10 -39 44 ; numbers 
#t $f ; Booleans 
hello frog ; symbols 
(80 87 11) ; list of numbers 


(frog newt salamander) ; list of symbols 
(10 lords a-leaping) ; list of mixed values 
((9 ladies dancing) (8 maids a-milking)) ; list of S-expressions 


An ordinary S-expression can be written directly in source code, preceded by a 
quote mark. 

From values we move to syntax, which is shown in Figure 2.2 on the facing page. 
Much of the core syntax should be familiar from Impcore; new forms include the 
let family (Section 2.6), lambda (Section 2.7), and lots of new literals. Some syntac- 
tic sugar is also new. Record definitions, short-circuit conditionals, and the cond 
form are expanded as described in Section 2.13; when and unless are expanded as 
described in Chapter 3 (Figure 3.3, page 204). 

After values and syntax, the last element of the language is the initial basis, 
starting with the primitives. 


* Primitives shared with Impcore include +, -, *, /, <, and >, which implement 
arithmetic and comparisons. The comparisons return Booleans, not num- 
bers: #t if the condition holds, and otherwise, #f. Applying any of these 
functions to a non-number is a checked run-time error, as is division by zero. 


Primitives that are new with Scheme include type predicates, which are used to 
identify a value’s form. 


* Each type predicate, symbo1?, number?, boolean?, null?, or function?, re- 
turns #t if its argument is of the named form, #f otherwise. Predicates 


def = (val variable-name exp) 


unit-test 
exp 

* 

* 

x 
let-keyword :: 
formals 
literal 
S-exp 
numeral 
*name 


Tokens are as in Impcore, except that if a quote mark ' occurs at the beginning of 


exp 

(define function-name (formals) exp) 
(record record-name [ { field-name} 1) 
(use file-name) 

unit-test 


(check-expect exp exp) 
(check-assert exp) 
(check-error exp) 


literal 

variable-name 

(set variable-name exp) 

(if exp exp exp) 

(while exp exp) 

(begin {exp}) 

(exp { exp} ) 

(let-keyword ( { [variable-name exp] } ) exp) 
(lambda (formals) exp) 

(&& {exp}) | Cll {exp}) 

(cond { [question-exp answer-exp] }) 
(when exp {exp} ) | (unless exp {exp}) 


let | let* | letrec 

{ variable-name} 

numeral | #t | #f | 'S-exp | (quote S-exp) 
symbol-name | numeral | #t | #f | ({S-exp}) 


token composed only of digits, possibly prefixed with a plus 
or minus sign 


token that is not a bracket, a numeral, or one of the “re- 
served” words shown in typewriter font 


a token, it is a token all by itself; e.g., 'yellow is two tokens. 


Each quoted S-expression (S-exp) is converted to a literal value by the parser. And 
each record definition is expanded to a sequence of true definitions, also by the 
parser; in other words, a record definition is syntactic sugar (Section 1.8, 
page 68), as marked by the x. Five forms of conditional expression are also 


syntactic sugar. All the other forms are handled by the eval function. 


Figure 2.2: Concrete syntax of wScheme 
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symbol?, number?, boolean?, and null? identify atoms—nul1l1? asks if the 
value is an empty list. Predicate function? identifies functions.? 


Other new primitives support lists: 


* Function cons adds one element to the front of a list. If vs (pronouced “veez”) 
is the empty list, then (cons v vs) is the singleton list (v). If vs is the non- 
empty list (v1 --+ Un), then (cons v vs) is the longer list (Vv v1 --- Up). 


In Scheme, cons has a quirk not common in other functional languages: it can be 
applied to any two values, not just to an element and a list. This quirk demands a 
fourth rule for the formation of j:Scheme values: 


4. If v; and v2 are values, then (cons vj v2) produces a value. 


Scheme values formed by rules 1, 2, and 4 are called fully general S-expressions. 

Calling (cons v1 v2) always produces a value, but the result a list of values ifand 
only if v2 is a list of values. Values made with cons are identified by type predicate 
pair?. 


* Calling (pair? v) returns #t if and only if v is a value produced by cons. 


Lists are interrogated by other primitives: 
* Function null? is used to distinguish an empty list from a nonempty list. 


* Function car returns the first element of a nonempty list; if vs is the non- 
empty list (v1 --- Un), then (car vs) is vy. If vs is any other value made 
with cons, like (cons v; v2), then (car vs) is also v,. If vs is () or is not 
made with cons, applying car to it is a checked run-time error. 


* Function cdr returns the remaining elements of a nonempty list. If vs is the 
nonempty list (v1 --- Un), then (cdr vs) is the list (v2--- Un), which con- 
tains all the elements of vs except the first. If vs is the singleton list (v1), 
(cdr vs) is (). If vs is any other value made with cons, like (cons v, v2), 
then (cdr vs) is v2. If vs is () or is not made with cons, applying cdr to it is 
a checked run-time error. 


The word “cdr” is pronounced as the word “could” followed by “er.” 


Primitives car and cdr can safely be applied to any value made with cons. 

The name cons stands for “construct,” which makes some kind of sense. The 
names car and cdr, by contrast, stand for “contents of the address part of regis- 
ter” and “contents of the decrement part of register,” which make sense only if we 
are thinking about the machine-language implementation of Lisp on the IBM 704. 
In the Racket dialect of Scheme, car and cdr are called by the more sensible names 
first and rest (Felleisen et al. 2018). 

pScheme includes an equality primitive that works on more than just numbers: 


* Function = tests atoms for equality. Calling (= v1 v2) returns #t if v; and v2 
are the same atom. That is, they may be the same symbol, the same number, 
or the same Boolean, or they may both be the empty list. Given any two val- 
ues that are not the same atom, including any functions or nonempty lists, 
(= v1 V2) returns #f. (To compare nonempty lists, we use the non-primitive 
function equal?, which is shown in chunk 104a.) 


3If you already know Scheme, or if you learn Scheme, you'll notice some differences. For example, 
in full Scheme, functions are called “procedures.” S-expressions are called “datums.” The syntax of the 
define form is different, and the val form uses the define keyword. The = primitive works only on 
numbers, and it is complemented by other equality functions like eq?, eqv?, and equal?. Full Scheme’s 
and and or forms are syntax, not functions, so they short-circuit, like wScheme’s && and | |. 


Last, the printing primitives are like Impcore’s printing primitives. Primitives 
print and print1n work with any value. 


* Calling (print v) prints a representation of v, but what you normally want 
is (println v), which prints the value and a newline. With either one, if v 
is a fully general S-expression, then the primitive prints everything known 
about it. But when v is a function, the primitives print only “<function>.” 


* Function printu prints UTF-8: Ifn is a number that corresponds to a Unicode 
code point, (printu n) prints the UTF-8 encoding of the code point. Code 
points newline, space, semicolon, quotemark, left-round, right-round, 
left-curly, right-curly, left-square, and right-square are predefined. 


Asin Impcore, only print1n, print, and printu have side effects; other primi- 
tives compute new values without changing anything. For example, applying cons, 
car, or cdr to a list does not change the list. 

The primitives that sScheme shares with Impcore are demonstrated in Chap- 
ter 1. The list primitives are demonstrated below, by applying them to values 
that are written as literals. Literals include numerals, Boolean literals, and quoted 
S-expressions (Figure 2.2, page 93). Using quoted S-expressions, we can demon- 
strate cons, car, and cdr: 


95a. (transcript 95a) = 95b> 
-> (cons 'a '()) 
(a) 
-> (cons 'a '(b)) 
(a b) 
-> (cons '(a) '(b)) 
((a) b) 
-> (cdr '(a (b (ce d)))) 
((b (c d))) 
-> (car '(a (b (ce d)))) 
a 


Primitive null? finds that the empty list is empty, but it finds that a singleton list 
containing the empty list is not empty: 


95b. (transcript 95a) += 95a 98> 
-> (null? '()) 
#t 
-> (null? '(())) 
#f 


In more complex examples, the primitives’ definitions have to be used carefully; 
a literal S-expression might look like a long list even when it’s not. For example, 
list (a (b (c d))) looks long, butit has only two elements: the symbol a and the list 
(b (c d)). Its cdr is therefore the single-element list ((b (c d))). 

Primitives cons, car, and cdr are often explained with diagrams. Any non- 
empty list can be drawn as a box that contains two pointers, one of which points to 
the car, and the other to the cdr. This box helps explain not only the behavior but 
also the cost of running Scheme programs, so it has a name—it is a cons cell. If the 
cdr of a cons cell is the empty list, there’s nothing to point to; instead, it is drawn 
as a slash. Using these conventions, the list (a b c) is drawn like this: 


per 


a b C 
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The car or cdr of a nonempty list is found by following the arrow that leaves 
the left or right box of the first cons cell. As another example, the S-expression 
(a (b (c d))) is drawn like this: 


LET Lu 
’ 
a. |e 
v 
> OER 
’ i 
c d 


Its cdr is simply what the first cell’s right arrow points at, which is, as above, 
((b (c d))): 


: 
N 


When complex structures are built from cons cells, car and cdr are often ap- 
plied several times in succession. Such applications have traditional abbreviations: 
96a. (predefined juScheme functions 96a) = 96bD> 

(define caar (xs) (car (car xs))) 
(define cadr (xs) (car (cdr xs))) 
(define cdar (xs) (cdr (car xs))) 


These definitions appear in chunk (predefined Scheme functions 96a), from which 
they are built into the zScheme interpreter itself and are evaluated when the in- 
terpreter starts. Definitions are built in for all combinations of car and cdr up to 
depth five, ending with cdddddr, but the others are relegated to the Supplement. 
If applying car or cdr several times in succession is tiresome, so is applying 

cons several times in succession. Common cases are supported by more prede- 
fined functions: 
96b. (predefined puScheme functions 96a) += <196a 99b> 

(define list1 (x) (cons x '())) 

(define liste (x y) (cons x (list1 y))) 

(define list3 (x y z) (cons x (list2 y z))) 
More cases, for list4 to list8, are defined in the Supplement. In full Scheme, 
all possible cases are handled by a single, variadic function, list, which takes any 
number of arguments and returns a list containing those arguments (Exercise 56). 

Three predefined functions are similar but not identical to functions found in 

Impcore: the Boolean functions and, or, andnot. Instead of Impcore’s 1 and 0, they 
return Boolean values. 
96c. (definitions of predefined j1Scheme functions and, or, and not 96c)= 

(define and (b c) (if b c b)) 

(define or (bc) (if b b c)) 

(define not (b) (if b #f #t)) 
Functions and and or inconveniently evaluate both arguments, even when the first 
argument determines the result. To evaluate only as much as is needed to make a 
decision, use the syntactic forms && and | | (Exercise 53). 


Table 2.3: The initial basis of «Scheme 


=). 


equal? 


Equality and inequality on atoms 
Recursive equality on fully general S-expressions 
(isomorphism, not object identity) 


/, *, -, +, mod 

>, <, >=, <= 

lcm, gcd, min, max 

lcem*, gcd*, max*, 
min* 


Integer arithmetic 

Integer comparison 

Binary operations on integers 

The same operations, but taking one nonempty list of 
integers as argument 


not, and, or 


Basic operations on Booleans, which, unlike their 
counterparts in full Scheme, evaluate all their 
arguments 


symbol?, number?, 
boolean?, 
null?, pair?, 
function? 
atom? 


Type predicates 


Type predicate saying whether a value is an atom 
(not a function and not a pair) 


cons, car, cdr 
caar, cdar, cadr, 
cddr,... 


list1, list2, 
list3, list4, 


The basic list operations 

Abbreviations for combinations of list operations, 
including also caaar, cdaar, caadr, cdadr, and so on, all 
the way to cddddr. 

Convenience functions for creating lists, including also 
list5 to list8 


append The elements of one list followed by the elements of 
another 

revapp The elements of one list, reversed, followed by another 

reverse A list reversed 

bind, find Insertion and lookup for association lists 

filter Those elements of a list satisfying a predicate 

exists? Does any element of a list satisfy a predicate? 

all? Do all elements of a list satisfy a predicate? 

map List of results of applying a function to each element of 
a list 

takewhile The longest prefix of a list satisfying a predicate 

dropwhile What’s not taken by takewhile 


foldl, foldr 


Elements of a list combined by an operator, which 
associates to left or right, respectively 


fs) 
curry 
uncurry 


Function composition 
The curried function equivalent to some binary function 
The binary function equivalent to some curried function 


printin, print 
printu 
error 


Primitives that print one value 

Primitive that prints a Unicode character 

Primitive that aborts the computation with an error 
message 
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The functions above are all part of jsScheme’s initial basis. The entire basis, in- 
cluding both primitive and predefined functions, is summarized in Table 2.3 on the 
preceding page. The primitives are discussed above, and predefined functions that 
are unique to Scheme are shown in this chapter in code chunks named (predefined 
pScheme functions 96a). Other predefined functions are defined exactly as in Imp- 
core; their definitions are relegated to the Supplement. 


2.3. PRACTICE I: RECURSIVE FUNCTIONS ON LISTS OF VALUES 


Primitives null?, car, and cdr are used to write functions that inspect lists and 
their elements. In Scheme, such functions are typically recursive. Even functions 
that iterate are usually written recursively; Scheme programmers rarely use set or 
while. To become fluent in writing your own recursive functions, you can imitate 
the many examples in this section: 


* Functions that are agnostic about the types of list elements 
* Functions that operate on lists of numbers 
* Functions the operate on lists of lists—that is, S-expressions 


* Functions that use lists to represent sets or finite maps 


2.3.1 Basic principles of programming with lists 


In Scheme, a list is created in one of two ways: by using '() or cons. In the style of 
the preceding section, 


Ll. The empty list '() is a list of values. 


L2. If visa value and vs is a list of values, (cons v vs) is a list of values. 


Like any other data type that can be created in multiple ways, a list is normally con- 
sumed by a function that begins with case analysis. Such a function distinguishes 
cases using nul1?, and when the list is not null—it was created by using cons—a 
typical function calls itself recursively on the rest of the list (the cdr). 
One of the simplest such functions finds the length of a list of values: 
98. (transcript 95a) += <95b 99aD 
-> (define length (xs) 
(if (null? xs) 
0 
(+ 1 (length (cdr xs))))) 


The length function typifies recursive functions that consume lists: when it sees an 
empty list, its recursion stops (the base case); when it sees a nonempty list, it calls 
itself recursively on (cdr xs) (an induction step). The name xs (pronounced “exes”) 
suggests a list of elements of unknown type; a single x suggests one such element. 

The behavior of length can be summarized in two equations: one for each form 
that its argument can take (forms L1 and L2 above). 


(length '()) =0 
(length (cons v vs)) = (+1 (length vs)) 


These equations are algebraic laws (Section 2.5). Algebraic laws often tell us exactly 
what to do with each possible form of input, making them a great way to plan an 
implementation. In practice, algebraic laws are also used for specification, proof, 
optimization, and testing. 

The algebraic laws for length specify exactly what length does; if you want to 
use length and you understand the laws, you never need to look at the code. But if 


it’s not obvious how the code works, it might help to look more closely at an example 
call. When (length '(a b)) is evaluated, here’s what happens: 


* In the initial call, xs = (ab). 


* The list (a b) is not the empty list, so (null? xs) returns #f. §2.3 
Practice I: 
Recursive 

functions on 

- List xs = (b). lists of values 


* The expression (+ 1 (length (cdr xs) )) is evaluated, where xs = (a b). Call- 
ing (cdr xs) returns list (b). When length is applied to (b), 


List (b) is not the empty list, so (nu11? xs) returns #f. 99 


Expression (+ 1 (length (cdr xs))) is evaluated. Calling (cdr xs) re- 
turns the empty list. When length is applied to the empty list, 

* List xs = (). 

* (null? xs) returns #t. 


* length returns 0. 


The call (length (cdr xs)) returns 0, so length returns 1. 
* The call (length (cdr xs)) returns 1, so length returns 2. 


As another example of recursive code specified using algebraic laws, let’s look 
at the predefined function append. Function append takes two lists, xs and ys, and 
it returns a list that contains the elements of xs followed by the elements of ys: 
99a. (transcript 95a) += 198 100a> 

-> (append '(moon over) '(miami vice)) 
(moon over miami vice) 

Interestingly, append never looks at ys; it inspects only zs. And like any list, 
zs is formed using either '() or cons. If xs is empty, append returns ys. If xs 
is (cons z zs), append returns z followed by zs followed by ys. The behavior of 
append can be specified precisely using two algebraic laws: 


(append '() ys) = Ys 
(append (cons Zz zs) ys) = (cons z (append zs ys)) 


In the code, argument xs holds xs, argument ys holds ys, z is (car xs), and zs is 
(cdr xs): 
99b. (predefined puScheme functions 96a) += <96b 100b> 
(define append (xs ys) 
(if (null? xs) 
ys 
(cons (car xs) (append (cdr xs) ys)))) 
cdr P 162a 

2.3.2 List reversal and the method of accumulating parameters a 


Algebraic laws can also help us design a list-reversal function—and make it effi- 
cient. To clarify the design, I condense the notation used to write laws, eliminating 
keywords and parentheses: 


Concept pScheme Condensed form 
Empty list me) € 

Element followed by list (cons z zs) Z+ 28 

List followed by list (append rs ys) 2XS- ys 


List reversed (reverse zs) R(as) 
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In condensed form, the append laws look like this: 


€- Ys = ys 
(z+ 28)- ys = z- (28+ ys) 


And the reversal laws look like this: 


R(e) =E€ 
R(z- 2s) = R(zs) +z 


Translated back to Scheme, the reversal laws are 


'O 


(simple-reverse (cons z zS)) = (append (simple-reverse zs) (list1 z)) 


(simple-reverse '()) 


The code looks like this: 
100a. (transcript 95a) += <199a 100d> 
-> (define simple-reverse (xs) 
(if (null? xs) 
Xs 
(append (simple-reverse (cdr xs)) (list1 (car xs))))) 
-> (simple-reverse '(my bonny lies over)) 
(over lies bonny my) 
-> (simple-reverse '(a b (c d) e)) 
(e (c d) b a) 

This simple-reverse function is expensive: append takes O(n) time and space, 
and so simple-reverse takes O(n”) time and space, where n is the length of the 
list. But list reversal can be implemented in linear time. In Scheme, reversal is 
made efficient by using a trick: take two lists, rs and ys, and return the reverse 
of xs, followed by (unreversed) ys. List xs is either empty or is z followed by zs, 
and the computation obeys these laws: 


R(z- zs)-+ ys = (R(zs) + z)- ys = R(zs) - (z- ys) 
Translated back to Scheme, the laws for “reverse-append” are 


(revapp '() ys) = Ys 
(revapp (cons Zz zs) ys) = (revapp zs (cons z ys)) 


The code looks like this: 


100b. (predefined puScheme functions 96a) += <199b 100c> 
(define revapp (xs ys) ; (reverse xs) followed by ys 
(if (null? xs) 
ys 
(revapp (cdr xs) (cons (car xs) ys)))) 
Function revapp takes time and space linear in the size of xs. Using it with an empty 
list makes predefined function reverse equally efficient. 
100c. (predefined uScheme functions 96a) += <1100b 103a> 
(define reverse (xs) (revapp xs '())) 


100d. (transcript 95a) += 100a 10la> 
-> (reverse '(the atlantic ocean) ) 
(ocean atlantic the) 


The trick used to make reversal efficient also applies to other problems. Be- 
cause the parameter ys is used to accumulate the eventual result, the trick is called 
the method of accumulating parameters. In full Scheme, a recursive function with 
accumulating parameters is typically compiled into a very tight loop. 


: , §2.3 
2.3.3 Lists of numbers: Sorting Practice I: 
: ; P : Recursive 
Functions like length, append, and reverse don't inspect the elements of any list— , 
functions on 


so they work on all lists of values. But other recursive functions may inspect ele- 
ments and use the values to make decisions. As an example, I present a function 
that works only on lists of numbers: insertion sort. 

Insertion sort considers one case for each form of input: an empty list of num- 
bers is sorted, and anonempty list (cons m ms), where mis anumber and msisa 
list ofnumbers, is sorted by recursively sorting ms, then inserting m into its proper 
position in the sorted list. 

Inserting m into its proper position is not trivial. Function insert must inspect 
the list of numbers into which m is inserted, so it too is recursive. Its behavior, 
which can depend on the relative order of two numbers m and k, is described by 
these laws: 


(insert m '()) = (list1 m) 
(insert m (cons k ks)) = (cons m (cons k ks)), whenm <k 
(insert m (cons k ks)) = (cons k (insert m ks)), when m > k 


Inthe code, if sortedis (cons k ks), then kis (car sorted) and ks is (cdr sorted). 
101a. (transcript 95a) += <100d 101b> 
-> (define insert (m sorted) 
(if (null? sorted) 
(list1 m) 
(if (< m (car sorted)) 
(cons m sorted) 
(cons (car sorted) (insert m (cdr sorted)))))) 


Function insert is now used, in insertion-sort, to insert m into a recursively 
sorted list: 


'O 


(insert (cons m ms)) = (insert m (insertion-sort ms)) 


(insertion-sort '()) 


101b. (transcript 95a) += <101a 102ap 
-> (define insertion-sort (ns) ebtersIne 
(if (null? ns) ae 
'O cons 
(insert (car ns) (insertion-sort (cdr ns))))) list1 
-> (insertion-sort '(4 3 2 6 8 5)) null? 


(23 45 6 8) 


2.3.4 Lists of prime numbers 


As another example of a recursive function that uses the values of list elements, 
I implement a well-known algorithm for finding prime numbers. The algorithm 
starts with a sequence of numbers from 2 to n, and it produces a prime p by taking 
the first number in the sequence, then continuing recursively after removing all 
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multiples of p. Because it identifies a multiple of p by trying to divide by p, the 
algorithm is called trial division.* 

The sequence of numbers from 2 to n is created by (seq 27); in general, 
(seq mn) returns a list containing numbers m,m + 1,m-+ 2,...,n. A multi- 
ple of p is identified by calling (divides? pn). 
102a. (transcript 95a) += <101b 102b> 

-> (define seq (m n) 
(if (> mn) '() (cons m (seq (+ 1m) n)))) 
-> (seq 3 7) 
(3 45 6 7) 
-> (define divides? (p n) (= (mod n p) 0)) 

Multiples of p are removed by calling (remove-multiples p ns), which returns 
those elements of ns that are not multiples of p. It considers both possible forms 
of ns: '() and (cons m ms). And when the input is (cons m ms), the behavior 
depends on a relation between p and m: 


(remove-multiples p '()) ='() 
(remove-multiples p (cons m ms)) = (remove-multiples p ms), when p divides m 


(remove-multiples p (cons m ms)) = (cons m (remove-multiples p ms) ), otherwise 


The code looks like this: 


102b. (transcript 95a) += <1102a 102c> 
-> (define remove-multiples (p ns) 
(if (null? ns) 
me) 
(if (divides? p (car ns)) 
(remove-multiples p (cdr ns)) 
(cons (car ns) (remove-multiples p (cdr ns)))))) 
-> (remove-multiples 2 '(2 3 45 6 7)) 
(3 5 7) 


Removal of multiples is the key step in trial division. The algorithm iterates 
over a sequence of numbers that contains a smallest prime p and no multiples of 
any prime smaller than p. Removing p and its multiples produces a prime, plus a 
new, smaller sequence with the same properties as the original sequence. Iteration 
proceeds until there are no more primes, as described by these algebraic laws: 


(primes-in (cons p ms)) = (cons p (primes-in (remove-multiples p ms))) 


(primes-in '()) ='0 


The code looks like this: 


102c. (transcript 95a) += <1102b 102d> 
-> (define primes-in (ns) 
(if (null? ns) 
'O 
(cons (car ns) (primes-in (remove-multiples (car ns) (cdr ns)))))) 
Applying primes-in to (seq 2n) produces all the primes up to n. 


102d. (transcript 95a) += <1102c 103b> 
-> (define primes<= (n) (primes-in (seq 2 n))) 
-> (primes<= 10) 
(2 35 7) 
-> (primes<= 50) 
(2 35 7 11 13 17 19 23 29 31 37 41 43 47) 


‘This algorithm is sometimes called the Sieve of Eratosthenes, but don’t be fooled: O’Neill (2009) will 
convince you that this algorithm is not what Eratosthenes had in mind. 


2.3.5 Coding with S-expressions: Lists of lists 


Even more recursion happens when a list element is itself a list, which can contain 
other lists, and so on. Such lists, together with the atoms (rule 1, page 92), constitute 
the ordinary S-expressions. 

An ordinary S-expression is either an atom or a list of ordinary S-expressions.° 
An atom is identified by predefined function atom?: 
103a. (predefined j1Scheme functions 96a) += <1100c 104a> 

(define atom? (x) 
Cor (symbol? x) (or (number? x) (or (boolean? x) (null? x))))) 

When an ordinary S-expression sx is passed to a function, that function must 
consider all possible forms of sx. As an example, function has? tells if an ordinary 
S-expression sx “has” an atom a. 


* If sx is an atom, then sx “has” a if and only if sx is a. Equality of atoms is 
tested using the primitive function =. 


* If sx is the empty list of S-expressions, it doesn’t have a. 


* If sx is the nonempty list (cons y ys), then sx has aif either y has a or ys 
has a. 


This specification is best written using algebraic laws: 


(has? sz a) = (= sx a), when x is an atom 
(has? (cons y z) a) = (has? y a) or (has? z a) 


These laws work with fully general S-expressions, which can be formed using value 
rule 4, not just rules 1 and 2 (Figure 2.1, page 91). That’s why, in the law, the cons 
cellis written (cons y z) and not (cons y ys). 

In the code, if sx is (cons y z), then y is (car sx) and zis (cdr sx). 


103b. (transcript 95a) += 102d 103¢> 
-> (define has? (sx a) 
(if (atom? sx) 
(= sx a) 
(or (has? (car sx) a) (has? (cdr sx) a)))) 


This code calls has? twice. It could be made faster by using an if expression instead 
of or, or by using short-circuit operator | | (Section 2.13.3, page 164). 
Function has? can search a list of lists of symbols: 


103c. (transcript 95a) += <1103b 104b> 
-> (val pangrams 77 www.rinkworks.com/words/pangrams.shtml, June 2018 
"((We promptly judged antique ivory buckles for the next prize.) 
(The quick red fox jumps over a lazy brown dog.) 
(Amazingly few discotheques provide jukeboxes.) 
(Heavy boxes perform quick waltzes and jigs.) 
(Pack my box with five dozen liquor jugs.))) 
-> (has? pangrams 'fox) 


#t 
-> (has? pangrams 'box) 
#t 
-> (has? pangrams 'cox) 
#f 


5The empty list '() is both an atom and a list of ordinary S-expressions. 
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2.3.6 Inspecting multiple inputs: Equality on S-expressions 


Functions like length, append, insert, and has? inspect only one list or one 
S-expression. A function that inspects two S-expressions must prepare for all forms 
of both inputs, for a total of four cases. As an example, function equal? compares 
two S-expressions for equality—they are equal if they are formed from the same 
atoms in the same way. Breaking the inputs down by cases, two atoms are equal 
if they are the same, as tested with primitive =. Two lists are equal if they contain 
(recursively) equal elements in equal positions. An atom and a nonempty list are 
never equal. 


(equal? sx1 8X2) = (= SZ 8ZQ), 

if sv, isan atom and sx2 is an atom 
(equal? sx; (cons w z))) = #f, if sv, isan atom 
(equal? (cons @ y) sX2) = #f, if svoisan atom 


(equal? (cons x y) (cons w z)) = (and (equal? x w) (equal? y z)) 


These laws call for four cases, but in an implementation, the first two laws can be 
combined: the second law calls for equal? to return #f, but when sz; is an atom 
and so is (cons w Z), (= 8&1 $£2) always returns false, so both cases where sx is 
an atom may use =: 
104a. (predefined juScheme functions 96a) += <1103a 106a> 
(define equal? (sx1 sx2) 
(if (atom? sx1) 


(= sx1 sx2) 
(if (atom? sx2) 
#f 


(and (equal? (car sx1) (car sxé2)) 
(equal? (cdr sx1) (cdr sx2)))))) 


The expected behavior is easily confirmed: 


104b. (transcript 95a) += <1103c 105a> 
-> (equal? 'a 'b) 
tf 
-> (equal? '(a (1 3) c) '(a (1 3) c)) 
#t 
-> (equal? '(a (1 3) d) '(a (1 3) c)) 
tf 
-> (equal? '(a bc) '(a b)) 
tf 
-> (equal? #f #f) 
#t 


More rigorous testing confirms both #f and (when possible) #t results for all four 
cases. 


2.3.7 Lists that represent sets 


In Scheme, as in any other language, a list with no repeated elements can repre- 
sent a set. As long as the set is small, this representation is efficient, and the set 
operations are easy to write and to understand. Operations emptyset, member?, 
add-element, size, and union are shown below; their algebraic laws are shown in 
comments. Other operations appear at the end of the chapter (Exercise 3). 


Function member? requires explicit recursion. 


105a. (transcript 95a) += <1104b 105b> 
-> (val emptyset '()) 
-> (define member? (x s) + (member? x '()) = #f 
(if (null? s) ; (member? x (cons x ys)) = #t 
#f ; (member? x (cons y ys)) = (member? x ys), 
(if (equal? x (car s)) ; when x differs from y 
#t 


(member? x (cdr s))))) 


Function add-element might be implemented recursively, but instead it calls 
member?. 


105b. (transcript 95a) += 105a 105¢> 
-> (define add-element (x s) 7 (add-element x s) = xs, when x is ins 
(if (member? x s) ; (add-element x s) = (cons x xs), 
Ss : when x is not ins 


(cons x s))) 
-> (val s (add-element 3 (add-element 'a emptyset))) 
(3 a) 
-> (member? 'a s) 
#t 


Functions size and union, like member?, are recursive. 


105¢e. (transcript 95a) += <1105b 105d> 
-> (define size (s) + (size '()) = 0 
(if (null? s) ; (size (cons x xs)) = (+ 1 (size xs)) 
0 
(+ 1 (size (cdr s))))) 
-> (define union (si s2) 7 (union '() se) = se 
(if (null? s1) ; (union (cons x xs) s2) = 
s2 : (add-element x (union xs s2)) 


(add-element (car s1) (union (cdr si) s2)))) 
-> (union s (add-element 2 (add-element 3 emptyset))) 
(a 2 3) 
Because member? tests for identity using equal?, it can recognize a list as an 

element of a set: 
105d. (transcript 95a) += 105¢ 106d> 

-> (val t (add-element '(a b) (add-element 1 emptyset))) 

((a b) 1) 

-> (member? '(a b) t) 

#t 
If member? used = instead of equal?, this last example wouldn't work; I encourage 
you to explain why (Exercise 4). 


2.3.8 Association lists 


A list of ordered pairs can represent a classic data structure of symbolic computing: 
the finite map (also called associative array, dictionary, and table). Finite maps are 
ubiquitous; for example, in this book they are used to represent the environments 
found in operational semantics and in interpreters. (In an interpreter or compiler, 
an environment is often called a symbol table.) 

A small map is often represented as an association list. An association list 
has the form ((kj a1) --- (km @m)), where each k; is a symbol, called a key, 
and each a; is an arbitrary value, called an attribute. A pair (k; a;) is made 
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with function make-alist-pair and inspected with functions alist-pair-key and 
alist-pair-attribute: 


(alist-pair-key (make-alist-pairka)) =k 
(alist-pair-attribute (make-alist-pair ka)) =a 


The pair is represented by a two-element list, so the three alist-pair functions 


Scheme, are implemented as follows: 
S-expressions, and  106a. (predefined jsScheme functions 96a) += 4104a 106b> 
first-class functions (define make-alist-pair (Ck a) (liste k a)) 
(define alist-pair-key (pair) (car  pair)) 
106 (define alist-pair-attribute (pair) (cadr pair)) 


A list of these pairs forms an association list, and when an association list is 
nonempty, the key and attribute of the first pair are retrieved by these auxiliary 


functions: 
106b. (predefined puScheme functions 96a) += <1106a 106c> 
(define alist-first-key (alist) (alist-pair-key (car alist))) 


(define alist-first-attribute (alist) (alist-pair-attribute (car alist))) 


An association list is operated on primarily by functions bind and find, which 
add bindings and retrieve attributes. Their behavior is described by these laws: 


(bindka'()) = (cons (make-alist-pair ka) '()) 
(bind k a (cons (make-alist-pair k a’) ps)) = (cons (make-alist-pair k a) ps) 
(bind k a (cons (make-alist-pair k’ a’) ps)) = 
(cons (make-alist-pair k’ a’) (bindkaps)), 
when k and k’ are different 


(find k '()) ='(C) 
(find k (cons (make-alist-pairk a) ps)) =a 
(find k (cons (make-alist-pair k’ a) ps)) = (find k ps) 
when k and k’ are different 
A missing attribute is retrieved as '(). 
106c. (predefined uScheme functions 96a) += <1106b 125a> 


(define bind (k a alist) 
(if (null? alist) 
(list1 (make-alist-pair k a)) 
(if (equal? k (alist-first-key alist)) 
(cons (make-alist-pair k a) (cdr alist)) 
(cons (car alist) (bind k a (cdr alist)))))) 
(define find (k alist) 
(if (null? alist) 
a@) 
(if (equal? k (alist-first-key alist)) 
(alist-first-attribute alist) 
(find k (cdr alist))))) 


Function bind is illustrated by this contrived example, which shows how the 
attribute for I is replaced by bind-ing I a second time: 


106d. (transcript 95a) += 105d 107a> 
-> (val demo-alist (bind 'I 'Ching '())) 
((I Ching)) 
-> (val demo-alist (bind 'E 'coli demo-alist)) 
((I Ching) (E coli)) 
-> (val demo-alist (bind 'I 'Magnin demo-alist)) 
(C(I Magnin) (E coli)) 
-> (find 'I demo-alist) 
Magnin 


As amore realistic example, an association list can store the locations of gro- 
ceries. Association list aisles shows where to find yams and butter, but not milk: 


107a. (transcript 95a) += 106d 107b> 
-> (val aisles (bind 'nog ‘dairy '())) 
((nog dairy)) 
-> (val aisles (bind ‘apple 'produce aisles)) 
((nog dairy) (apple produce) ) 
-> (val aisles (bind 'yam 'produce aisles)) 
((nog dairy) (apple produce) (yam produce)) 
-> (val aisles (bind 'butter 'dairy aisles)) 
((nog dairy) (apple produce) (yam produce) (butter dairy)) 
-> (val aisles (bind 'chex 'cereal aisles)) 
((nog dairy) (apple produce) (yam produce) (butter dairy) (chex cereal)) 
-> (find 'yam aisles) 


produce 

-> (find 'butter aisles) 
dairy 

-> (find 'milk aisles) 
O 


2.4 RECORDS AND TREES (MORE DATA) 


S-expressions can code all forms of lists and trees: a lot of structured data. But 
when all data are S-expressions, every interesting structure is made with cons cells. 
Such structures are traversed with combinations of car and cdr, and using car and 
cdr for everything is too much like programming in assembly language. 
Functions like car and cdr are perfect for data whose size or structure may vary. 
But many data structures store a fixed number of elements in known locations, 
like aC struct. In Scheme, such structures can be represented by records. In this 
section, records are introduced by example, then used to represent binary trees. 


2.4.1 Records 


As an example of a record, a “frozen dinner” is a container that holds these parts: 


* Aprotein 

* Astarch 

« Avegetable 
* Adessert 


In Scheme, such a record is defined like this: 


107b. (transcript 95a) += <107a 108a> 
-> (record frozen-dinner [protein starch vegetable dessert]) 


The record is a lot like a C struct or a Java object: 


* Like a C struct, a frozen-dinner record always holds exactly four values: 
the protein, the starch, the vegetable, and the dessert. As in C, these values 
are called the members or fields of the record. 


* As in C, each field is accessed by using its name. But where C uses dot 
notation, writing .starch after a struct (or quite commonly, ->starch 
after a pointer to a struct), wScheme uses an accessor function, applying 
frozen-dinner-starch to a record. 
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pScheme records are allocated and initialized differently from C structs. Astruct 
is allocated by malloc (or in C++, new), and each individual field is initialized by 
an individual assignment. A jsScheme record is allocated and initialized by a con- 
structor function, which receives the initial values of ail the fields as its arguments. 
The constructor function is a bit like a constructor in C++ or Java, except its be- 
havior is determined by the language and cannot be changed by the programmer. 
The constructor function expects one argument per field of the record, in the order 
in which they appear, as follows: 
108a. (transcript 95a) += <107b 108b> 

-> (make-frozen-dinner 'steak 'potato 'green-beans 'pie) 

(make-frozen-dinner steak potato green-beans pie) 

-> (make-frozen-dinner 'beans 'rice 'tomatillo 'flan) 

(make-frozen-dinner beans rice tomatillo flan) 

-> (frozen-dinner-starch it) 

rice 

The accessor functions and constructor function are defined automatically by 

the record definition form, which also defines a type predicate. The type predicate 
frozen-dinner? may receive anyvalue, and it returns #t if and only if the value was 
built using constructor function make-frozen-dinner:° 
108b. (transcript 95a) += <1108a 108¢> 

-> (frozen-dinner? (make-frozen-dinner 'beans 'rice 'tomatillo 'flan)) 

#t 

-> (frozen-dinner? '(beans rice tomatillo flan)) 

#f 


When a record form is evaluated, the interpreter prints the names of the func- 
tions that it defines: 


108c. (transcript 95a) += <1108b 108d> 
-> (record frozen-dinner [protein starch vegetable dessert]) 
make-frozen-dinner 
frozen-dinner? 
frozen-dinner-protein 
frozen-dinner-starch 
frozen-dinner-vegetable 
frozen-dinner-dessert 


A long name like frozen-dinner-protein is necessary because some other 

record might also have a protein field: 
108d. (transcript 95a) += <1108c 109a> 

-> (record nutrition [protein fat carbs]) 

make-nutrition 

nutrition? 

nutrition-protein 

nutrition-fat 

nutrition-carbs 


A short name like .protein won't work in Scheme, because there is no type 
system to tell us which record is meant. Long names, like nutrition-protein 
and frozen-dinner-protein, say explicitly which record is meant (nutritional- 
information records and frozen-dinner records, respectively). 


®Not quite: In pzScheme, but not in full Scheme, the type predicate can be fooled by a record that is 
forged using cons (Section 2.13.6). 


Functions defined by record satisfy algebraic laws, which say that we get out 
what we put in: 


(frozen-dinner? (make-frozen-dinner p sv d)) = #t 
(frozen-dinner? v) = #f, 

where v is not made by make-frozen-dinner 
(frozen-dinner-protein (make-frozen-dinner psvud)) =p $2.4 
(frozen-dinner-starch (make-frozen-dinner psud)) =s Records and trees 
(frozen-dinner-vegetable (make-frozen-dinner psud)) =v (more data) 
(frozen-dinner-dessert (make-frozen-dinner psud)) =d 109 


2.4.2 Binary trees 


Records, like C structs, make great tree nodes. For example, in a binary tree, 
a node might contain a tag and two subtrees. A binary tree is either such a node or 
is empty. A node can be represented as a node record, and the empty tree can be 
represented as #f. 
109a. (transcript 95a) += <1108d 109b> 

-> (record node [tag left right]) 

make-node 

node? 

node-tag 

node-left 

node-right 


The node functions obey these laws: 


((node?) (make-node t left right)) = #t 
((node?) atom ) = #f 
(node-tag (make-node t left right)) =t 
(node-left (make-node t left right)) = left 
(node-right (make-node t left right)) = right 


The set of tagged binary trees can be defined precisely, by induction. The set 
BINTREE(T) contains tagged binary trees with tags drawn from set T: 


#f © BINTREE(T) 


leT t; € BINTREE(T) to € BINTREE(T) frozen-dinner- 
(make-node1lt1t2) € BINTREE(T) Patan! 


107b 
Such a tree is either built with make-node or is #f, as in this example: make-frozen- 


109b. (transcript 95a) += 109a 110ab dinner —-107b 
-> (val example-sym-tree 
(make-node 'A 
(make-node 'B 
(make-node 'C #f #f) 
(make-node 'D #f #f)) 
(make-node 'E 
(make-node 'F 
(make-node 'G #f #f) 
(make-node 'H #f #f)) 
(make-node 'I #f #f)))) 
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The example tree might be drawn as follows: 


A 
a 
ge oo 
c D F I 
LX 
G H 


Tagged binary trees are consumed by functions whose internal structure fol- 
lows the structure of the input. Just as a list-consuming function must handle 
two forms, cons and '(), a tree-consuming function must handle two forms: 
make-node and empty. The forms can be distinguished by predicate empty-tree?: 
110a. (transcript 95a) += <109b 110b> 

-> (define empty-tree? (tree) (= tree #f)) 

One example tree-consuming function is a classic tree traversal: the preorder 
traversal: 
110b. (transcript 95a) += <110a 118a> 

-> (define preorder (tree) 
(if Cempty-tree? tree) 
'O 
(cons (node-tag tree) 
(append 
(preorder (node-left tree) ) 
(preorder (node-right tree)))))) 
-> (preorder example-sym-tree) 
(ABCODEF GH I) 


Inorder and postorder traversals are left for you to implement (Exercise 11). 


2.5 COMBINING THEORY AND PRACTICE: ALGEBRAIC LAWS 


Throughout this chapter, functions are described by algebraic laws. The laws help 
us understand what the code does (or what it is supposed to do). Algebraic laws also 
help with design: they can show what cases need to be handled and what needs to 
be done in each case. Translating such laws into code is much easier than writing 
correct code from scratch. 

Algebraic laws have many other uses. Any algebraic law can be turned into a 
test case by substituting example data for metavariables; for example, QuickCheck 
(Claessen and Hughes 2000) automatically substitutes a random input for each 
metavariable. Algebraic laws are also used to specify the behavior of abstract types, 
to simplify code, to improve performance, and even to prove properties of code. 

Algebraic laws work by specifying equalities: in a valid law, whenever values 
are substituted for metavariables, the two sides are equal. (The values substituted 
must respect the conditions surrounding the law. For example, if ns stands for a 
list of numbers, we may not substitute a Boolean for it.) The substitution principle 
extends beyond values; a valid law also holds when program variables are substi- 
tuted for metavariables, and even when pure expressions are substituted for meta- 
variables. A pure expression is one whose evaluation has no side effects: it does 
not change the values of any variables and does not do any input or output. And 
for our purposes, a pure expression runs to successful completion; if an expres- 
sion’s evaluation doesn’t terminate or triggers a run-time error, the expression is 
considered impure. 

The equality specified by an algebraic law is a form of observational equivalence: 
if e; = e2, anda program contains €), we can replace e; with e2, and the program 


won't be able to tell the difference. That is, running the altered program will have 
the same observable effect as the original. Replacing e; with eg may, however, 
change properties that can’t be observed by the program itself, such as the time 
required for completion or the number of locations allocated. When an algebraic 
law is used to improve performance, changing such properties is the whole point. 

In the sections above, algebraic laws are used only to show how to implement 
functions. In this section, they are also used to specify properties of functions and 
of combinations of functions, and to prove such properties. 


2.5.1 Laws of list primitives 


Algebraic laws can be used to specify the behaviors of primitive functions. After 
all, programmers never need to see implementations of cons, car, cdr, and nu11?; 
we just need to know how they behave. Their behavior can be specified by oper- 
ational semantics, but operational semantics often gives more detail than we care 
to know. For example, if we just want to be able to use car and cdr effectively, 
everything we need to know is captured by these two laws: 


(car (consxy)) =z 
(cdr (consxy)) =y 


These laws also tell us something about cons: implicitly, the laws confirm that cons 
may be applied to any two arguments x and y, even if y is not a list (rule 4, page 91). 
Use of cons cells and '() to represent lists is merely a programming convention. 

To capture cons completely also requires laws that tell us how a cons cell is 
viewed by a type predicate, as in these examples: 


(pair? (cons x y)) = #t 
(null? (cons x y)) = #f 


The laws above suffice to enable us to use cons, car, and cdr effectively. Noth- 
ing more is required, and any implementation that satisfies the laws is as correct 
as any other. To develop an unusual implementation, try Exercise 39. 


2.5.2 Developing laws by classifying operations 


How many laws are enough? To know if we have enough laws to describe a data 
type T, we analyze the functions that involve values of type T’. 


* A function that makes a new value of type T is a creator or a producer. A cre- 
ator is either a value of type T all by itself, or it is a function that returns a 
value of type T’ without needing any arguments of type 7’. As an example, 
'() is acreator for lists. A producer is a function that takes at least one ar- 
gument of type T’, and possibly additional arguments, and returns a value of 
type T’. As an example, cons is a producer for lists. 


Creators and producers are sometimes grouped into a single category called 
constructors, but “constructor” is a slippery word. The grouping usage comes 
from algebraic specification, but “constructor” is also used in functional pro- 
gramming and in object-oriented programming—and in each community, 
it means something different. 


- A function that takes an argument of type T' and gets information out of it 
is an observer. An observer “looks inside” its argument and produces some 
fact about the argument, or perhaps some constituent value, which may or 
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may not also be of type T. Observers are sometimes also called selectors or 
accessors. As examples, primitives car, cdr, pair?, and null? are observers 
for lists. 


Creators, producers, and observers have no side effects. A function that has 
side effects on an existing value of type T is a mutator. Mutators, too, can 
fit into the discipline of algebraic specification. An explanation in depth is 
beyond the scope of this book, but a couple of simple examples appear in Sec- 
tion 9.6.2 (page 547). For more, see the excellent book by Liskov and Guttag 
(1986). 


This classification of functions tells us how many laws are enough: there are 
enough laws for type T if the laws specify the result of every permissible combina- 
tion of observers applied to creators and producers. By this criterion, our list laws 
aren't yet complete; they don’t specify what happens when observers are applied 
to the empty list. Such observations are specified by these laws: 


(pair? '()) = #f 
(null? '()) = #t 


Not all observations of the empty list are permissible. An observation would cause 
an error, like (car '()), isn't specified by any law, and so it is understood that the 
observation is impermissible. This convention resembles the convention of the 
operational semantics, where if an evaluation causes an error, no rule applies. 

Laws for rich data structures can be extensive. Because S-expressions include 
both lists and atoms, they have lots of creators, producers, and especially observers. 
Laws for all combinations would be overwhelming; only a few Boolean laws are 
sketched below. 


2.5.3 Boolean laws 


For the Booleans, values #t and #f act as creators, the syntactic form if acts like 
an observer, and the predefined function not is a producer. Their interactions are 
described by these laws: 


(if#tzry) =x 
(if #f ry) =y 

(if (not p) ay) = Gif py x) 
(if p#f #t) = (not p) 


If p is guaranteed to be Boolean, one more law is valid: 
(if p#t#f) =p 


This law, which is frequently overlooked, is also valid if the result of the if ex- 
pression is used only as a condition in other if expressions (or while expressions). 
Whenever possible, it should be used to simplify code. 


2.5.4 Abstract finite-map laws 


Laws for association lists (Section 2.3.8) tell us that find returns the most recent 
property added with bind: 


(findk (bindk am)) =a 
(find k (bind k’ am)) = (find k m), when k is different from k’ 


These laws are justified by appealing to the implementations in Section 2.3.8. 
But when a finite map gets large, those implementations aren't good enough; 
we need a more efficient data structure, like a binary search tree or even a red- 
black tree. These data structures, or any data structure that obeys the same laws, 
can serve as a drop-in replacement for the less efficient association list. (In another 
data structure, application of find to the empty map might cause an error, so no 
law for that case is included.) 


2.5.5 Laws that state properties of functions 


Not every set of laws fully specifies the behavior of the functions it describes. Some- 
times a law states a property that a function ought to have, without nailing down 
its behavior in every case—as in the following examples: 


(and pq) = (and q p) 

(and p#t) =p 

(and p #f) = #f 

(or pq) = (or gp) 
(or p#t) = #t 
(or p#f) =p 
(append (cons x '()) xs) = (cons x xs) 
(append (append zs ys) zs) = (append xs (append ys zs)) 


(reverse (reverse %S)) = x8 


These laws, which I often use in my own programming, are great for simplify- 
ing code. They also make excellent laws for “property-based” testing (Claessen and 
Hughes 2000). 


2.5.6 Laws and proof 


Algebraic laws enable a new, elegant form of proof. What good is a new form of 
proof? It proves more interesting facts with less work then operational semantics. 
In principle, anything we might prove about a sScheme program can be proved 
using the operational semantics. But using operational semantics to prove prop- 
erties of programs is like using assembly language to write them: it operates at so 
low a level that it’s practical only for small problems. Operational semantics is best 
used only to prove laws about primitive functions and syntactic forms. Those laws 
can then be used to prove laws about functions, which can be used to prove laws 
about other functions, and so on. In proof, laws play a similar role to the role that 
functions play in coding: they enable us to break problems down hierarchically. 

These hierarchical proofs are founded on proofs about primitives and syn- 
tax. Unfortunately, the foundational proofs can be quite challenging; for exam- 
ple, although no program can tell the difference between the two expressions 
(let ({x 1983]) x) and just 1983, they do not have exactly the same semantics: 
one allocates a fresh location and the other doesn’t. The extra location can’t be 
observed, but to prove it requires techniques that are far beyond the scope of this 
book. 

What we do in this book is freely substitute one pure expression for another, 
provided they always evaluate to equal values—even if they don’t have identical ef- 
fects on the store. This substitution of equals for equals is a simple, powerful proof 
technique, and it works not just on primitives and simple syntactic forms, but also 
on function applications. To substitute for a function application, we expand the 
body of the function by replacing each formal parameter with the corresponding 
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actual parameter. As long as there are no side effects, this too is substitution of 
equals for equals. 

Substitution is justified by algebraic laws: an algebraic law says, “these two 
sides are equal, and so one may be freely substituted for the other.” This tech- 
nique is called equational reasoning, and the resulting proofs are sometimes called 
calculational proofs. It is demonstrated in the next section. 


2.5.7 Using equational reasoning to write proofs 


Equational reasoning can be used to prove the laws for append and length given 
in Section 2.3.1. The first append law on page 99 says that (append '() ys) = ys. 
To prove it, I first substitute for append’s formal parameters, then apply the “null- 
empty” law from Section 2.5.2 and the “if-true” law from Section 2.5.3: 


(append '() ys) 
= {substitute actual parameters '() and ys in definition of append} 
(if (null? '()) 
ys 
(cons (car '()) (append (cdr '()) ys))) 
= {null-empty law} 


(if #t 
Ys 
(cons (car '()) (append (cdr '()) ys))) 
= {if-#t law} 
Ys 


Each step in the proof is a single equality, presented in this form: 


term, 
= { justification that term, = term} 
term, 


These steps are chained together to show that every term is equal to every other 
term, and in particular that the first term is equal to the last term. In the example 
above, the chain of equalities establishes that (append '() ys) = ys. The append- 
cons law, (append (cons z zs) ys) = (cons z (append zs ys)), is proved in simi- 
lar fashion. 

The key step in the proof is the expansion of the definition of append. As an- 
other example of such an expansion, I prove that the length of a cons cell is one 
more than the length of the second argument: 


(length (cons y ys)) = (+1 (length ys)) 


Again the expansion is the first step: in the definition of length, the actual param- 
eter (cons y ys) is substituted for the formal parameter xs: 


(length (cons y ys)) 
= {substitute actual parameter in definition of length} 
(if (null? (cons y ys)) 
0 
(+ 1 (length (cdr (cons y ys))))) 


= {nul1?-cons law} 


(if #f 
0 
(+ 1 (length (cdr (cons y ys))))) 
= {if-#f law} 
(+ 1 (length (cdr (cons y ys)))) 
= {cdr-cons law} 
(+ 1 (length ys)) 

Expanding a function’s definition works, but it can make a proof long, verbose, 
and hard to follow. A function’s definition should be expanded as little as possible— 
just enough to prove the laws that describe its implementation. Then, in future 
proofs, only those laws are needed. As an example of using such a law, I prove that 
appending a singleton list is equivalent to cons. I still substitute actual parameters, 
but now instead of substituting them for the formal parameters of append, I sub- 
stitute them for the metavariables of the append-cons law on the preceding page. 


The key step is again the first step, where I substitute x for z and '() for zs, leaving 
ys unchanged: 


(append (cons x '()) ys) 

= {substitute actual parameters in the append-cons law} 
(cons x (append '() ys)) 

= {apply the append-empty law, substituting the right-hand side for the left} 
(cons x ys) 


The examples above prove properties about the application of append or length 
to a list that is known to be short (empty or singleton). But useful properties aren't 
limited to short lists; for example, appending two lists adds their lengths, even 
when the first argument to append is arbitrarily long. The computation involves 
a recursive call to append, and proving general facts about recursive functions usu- 
ally demands proof by induction. In particular, laws about lists and S-expressions 
are proved by structural induction: 


* Prove the law holds for every base case. In the case of a list, prove that the 
law holds when the list is empty. 


* Prove every induction step by assuming the law holds for the constituents. 
Again in the case of a list, prove the case for a nonempty list (cons z zs) by 
assuming the induction hypothesis for the smaller list zs. 


As an example, I prove the law 


(length (append xs ys)) = (+ (length xs) (length ys) ) 


The proof is by structural induction on zs. In the base case, xs is empty: 


(length (append '() ys)) 
= {append-empty law} 
(length ys) 
= {zero is the additive identity} 
(+ 0 (length ys)) 
= {length-empty law, from right to left} 
(+ (length '()) (length ys)) 
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In the induction step, rs is not empty, and therefore there exist a z and zs such 
that xs = (cons z zs). 


(length (append xs ys)) 
= {by assumption that xs is not empty, 7s = (cons z zs)} 
(length (append (cons z zs) ys)) 
= {appeal to the append-cons law} 
(length (cons z (append zs ys))) 
= {appeal to the length-cons law} 
(+ 1 (length (append zs ys))) 
= {apply the induction hypothesis} 
(+ 1 (+ (length zs) (length ys))) 
= {associativity of +} 
(+ (+ 1 (length zs)) (length ys)) 
= {length-cons law, from right to left} 
(+ (length (cons z zs)) (length ys)) 
= {by the initial assumption that xs = (cons z zs)} 
(+ (length xs) (length ys)) 


These examples should teach you enough so that you can do Exercises 16 to 26 
starting on page 183. 


2.5.8 Source of the induction principle: Inductively defined data 


For a law like (length (append xs ys)) = (+ (length zs) (length ys)), what 
cases need to be proved? One for each possible way that xs can be constructed. 
Since zs is a list of values, I claim there are only two ways: '() and cons. This 
claim can be made precise with the help of a proof system that says what a list is. 

“List” is a parametric abstraction; for example, there are “lists of numbers,” “lists 
of Booleans,” “lists of values,” and so on. To notate the set of all lists whose elements 
are in set A, I write LIST(A). This set can be defined by a proof system for set 
membership. The judgment form is v € LIST(A), and it is proved by showing 
that v is either '() or a suitable cons cell: 


EMPTYLIST CONSLIST 
a€A as € LIST(A) 
'C) € LIST(A) (consaas) € LIST(A) 


A value v isin LIST (A) if and only if there is a proof of v € LIST(A). 

Now let’s prove that some property P holds for every v in LIST(A). Formally 
that means, “if there is a derivation of v € LIST(A), then P(v).” The proof is a 
metatheoretic proof! It’s just like the metatheoretic proofs in Chapter 1 (page 59), 
except the underlying proof system isn’t the operational semantics of Impcore— 
it’s the proof system for v € LIST(A). But the structure is the same; in partic- 
ular, a proof about LIST(A) needs a case for each rule in the proof system for 
v € LIST(A), and that means one case for '() and one for cons. 

Metatheoretic proof techniques apply to other sets of values, provided those 
sets are defined inductively, by a proof system. For example, S-expressions can be 
defined by a proof system. The forms of S-expression that are of most interest to 
Scheme programmers are the ordinary S-expressions SEXP (the ones that can be 
written with quote) and the fully general S-expressions SEXP wg (the ones that are 
made with atoms and cons). To write their proof systems, I write SYM, NUM, 


and BOOL for primitive sets of atoms. An ordinary S-expression is either an atom 
or a list of S-expressions, and its judgment form is v € SEXPo: 


v€ SYM v€ NUM v € BOOL v € LIST(SEXPo) 
v € SEXPo v € SEXPo v € SEXPo v € SEXPo 


A fully general S-expression is either an atom or a pair of S-expressions: 


ve SYM v € NUM v € BOOL 
v € SEXP ra v € SEXP rg v € SEXP ra 'C) € SEXP ra 


V~E SEXP rq v2 € SEXP ra 
(cons v1 v2) € SEXP ra 


Not all fully general S-expressions can be written with Scheme’s quote form; for 
example, the result of evaluating (cons 2 2) cannot be written with a quote. 

Inductively defined data is so common that it’s useful to have a shorthand nota- 
tion for it. The most common notations, including the datatype definition forms 
of Standard ML (Chapter 5) and jsML (Chapter 8), are related to recursion equations. 
For example, the simplest recursion equation for LIST (A) looks like this: 


LIST(A) = {'O}U{ (cons v vs) |v € AA us € LIST(A) }. 


This equation can’t quite be taken as a definition, unless we say that LIST (A) is 
the smallest set that satisfies the equation. 
S-expressions can be described by similar equations: 


SEXPo9 = SYM UNUM U BOOLU LIST (SEXPo) 
SEXP rg = SYM UNUM U BOOLU{'()}U 
{ (CONS V1 V2) | v1, © SEXP rg A v2 € SEXP rg 7 


2.6 LANGUAGE IT: LOCAL VARIABLES AND let 


While a lot can be done with just formal parameters, big functions need local vari- 
ables. Ina procedural language like C or Impcore, local variables can be introduced 
without being initialized, and they are often assigned to more than once. But ina 
functional language like Scheme, local variables are always initialized when intro- 
duced, and afterward, they are rarely assigned to again. 

In Scheme, local variables are introduced by let binding. A let binding is of- 
ten hand-written as “let x = e’ ine,’ which means “evaluate e’, let x stand for 
the resulting value, and evaluate ec.” In Scheme, the same binding is written 
(let ([x e’]) e). In general, Scheme’s let form binds a collection of values: 


(let ([2%1 €1] ++ [%n €n]) ©) 


This let expression is evaluated as follows: First evaluate the right-hand sides 
e; through e,,; call the results v1,...,U,. Next, extend the local environment so 
that x, stands for v,, and so on. Finally, in the extended environment, evaluate 
the body e; the value of the body becomes the value of the entire let expression. 
The let form helps us avoid repeating computation, and it helps make code 
readable. To enhance its readability, I write its bindings in square brackets. 
(In Scheme, in full Scheme, and in all the bridge languages, square brackets mean 
the same as round brackets (“parentheses”). I typically use round brackets to wrap 
expressions, definitions, and lists of formal parameters; I use square brackets to 
wrap other kinds of syntax, like binding pairs or local-variable declarations.) 
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A let form can be thought of as naming the result of a computation. As an exam- 
ple, let’s compute the roots of the quadratic equation: ax? + bx +c = 0. From 
the quadratic formula, the roots are x = —2=v?"—4ac hee Although this formula is 
not much use without real numbers, it can still be implemented in wScheme, and 
it can compute roots of such equations as x? + 32 — 70 = 0. Decent candidates to 
be named with let are the values of subformulas —b, Vb? — 4ac, and 2a: 
118a. (transcript 95a) += <110b 118b> 

(definition of sqrt $318b) 
-> (define roots (a b c) 


(let ([minus-b (negated b)] 
[discriminant (sqrt (- (* b b) (* 4 (* a c))))] 
[two-a (* 2 a)]) 


(liste (/ (+ minus-b discriminant) two-a) 
(/ (- minus-b discriminant) two-a)))) 
-> (roots 1 3 -70) 
(7 -10) 

In a let expression, all of the right-hand sides are evaluated before any of the 
x;’s are bound. Itis often more useful to evaluate and bind one expression at a time, 
in sequence, so that right-hand side e; can refer to the values named 71,..., %;_1. 
Sequential binding is implemented by the let* form. This form has the same struc- 
ture as let, but after evaluating the first right-hand side e,, it extends the environ- 
ment by binding the result to x1. Then it evaluates e2 in the extended environment, 
binds the result to x2, and so on. 

The difference between let and let* can be illustrated by a contrived example: 
118b. (transcript 95a) += 118a 118¢> 

-> (val x 'global-x) 
-> (val y 'global-y) 


-> (let 
([x 'local-x] 
[y x]) 


(list2 x y)) 

(local-x global-x) 
In this example, because the right-hand sides in a let are evaluated in the original 
environment, the x in [y x] refers to the global definition of x. Using let*, the same 
structure works differently: 
118¢. (transcript 95a) += <118b 119ap 

-> (val x 'global-x) 

-> (val y 'global-y) 


-> (let* 
([x 'local-x] 
[y x]) 


(list2 x y)) 
(local-x local-x) 
In this example, because the right-hand sides in a let* are evaluated and bound in 
sequence, the x in [y x] refers to the local definition of x. 

Any let* expression can be simulated with a nested sequence of let expres- 
sions, but let* is more readable and more convenient. As evidence of let*'’s utility, 
I show a level-order traversal (also called breadth-first traversal) of a binary tree. This 
traversal visits every node on one level before visiting any node on the next level. 
In effect, it visits nodes in order of distance from the root. For example, level-order 
traversal of the tree on page 109 visits the nodes in the order (ABECDFIGH). 

Level-order traversal uses an auxiliary data structure: a queue of nodes not yet 
visited. Traversal starts with a queue containing only the root, and it continues until 
the queue is empty. When the queue is not empty, the traversal visits the node at the 


front of the queue, then enqueues the node’s children at the end. The implemen- 
tation needs queue operations emptyqueue, front, without-front, and enqueue: 


119a. (transcript 95a) += <1118c 119b> 
-> (val emptyqueue '()) 
-> (define front (q) (car q)) 
-> (define without-front (q) (cdr q)) 
-> (define enqueue (t q) 
(if (null? q) 

(list1 t) 

(cons (car q) (enqueue t (cdr q))))) 
-> (define empty? (q) (null? q)) 


This implementation of queues is woefully inefficient—it has the same cost as 
append—but it’s simple. I encourage you to do better (Exercise 13) and also to de- 
scribe the queue’s behavior using algebraic laws (Exercise 14). 

The traversal is performed recursively by auxiliary function level-order-of-q, 
which receives an initial queue that contains only the tree to be traversed. It uses 
let* to bind the first element to the name hd, which is then used both to make a 
new queue newg and to make the result in the body. 


119b. (transcript 95a) += 4119a 119¢> 
-> (define level-order-of-q (queue) 
(if (empty? queue) 
m@) 
(let* ([hd (front queue) ] 
[tl (without-front queue) ] 
[newq (if (empty-tree? hd) 
tl 
(enqueue (node-right hd) 
(enqueue (node-left hd) t1)))]) 
(if (node? hd) 
(cons (node-tag hd) (level-order-of-q newq)) 
(level-order-of-q newq))))) 
-> (define level-order (t) 
(level-order-of-q (enqueue t emptyqueue) )) 
-> (level-order example-sym-tree) 
(ABECODFTI GH) 


The example code names three queues: queue, t1, and newq. Picking the wrong 
one can cause an error; for example, if queue is used place of t1, the function will 
loop. In an idiomatic imperative function, such an error wouldn't occur; the func- 
tion would use just one variable, queue, whose value would change over time. In an 
idiomatic applicative function, the same error can also be avoided; by clever use 
of let*, the name queue can be repeatedly rebound so that it always refers to the 
queue of interest: 


119¢. (transcript 95a) += <119b 120aD 
-> (define level-order-of-q (queue) 
(if (empty? queue) 
me) 
(let* ([hd (front queue) ] 
[queue (without-front queue) ] 
[queue (if (empty-tree? hd) 
queue 
(enqueue (node-right hd) 
(enqueue (node-left hd) queue)))]) 
(if (node? hd) 
(cons (node-tag hd) (level-order-of-q queue) ) 
(level-order-of-q queue))))) 
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120a. (transcript 95a) += <119c 120b> 
-> (define level-order (t) 
(level-order-of-q (enqueue t emptyqueue))) 
-> (level-order example-sym-tree) 
(ABECODFTIG H) 


Both the imperative and the applicative idioms accomplish the same goal: they use 
just one name, queue, and at each point in the program, it means the right thing. 

The let and let* forms have a recursive sibling, letrec, which has yet a third 
set of rules for the visibility of the bound names x;. In a let expression, none of 
the x;’s can be used in any of the e;’s. In a let* expression, each 7; can be used in 
any e,; with j > i, thatis, an x can be used in all the e’s that follow it. Ina letrec ex- 
pression, all of the x,;’s can be used in all of the e,’s, regardless of order. The letrec 
form is used to define recursive functions. A simple example appears on page 135, 
but a detailed explanation is best deferred to the formal treatment of lambda and 
closures (Section 2.11.2). 


2.7 LANGUAGE III: FIRST-CLASS FUNCTIONS, lambda, AND LOCATIONS 


In Impcore, as in C, functions can be defined only at top level. And in Impcore, 
functions are not values. In C, functions are not quite values either, but a pointer 
to a function is an ordinary value, and it can be used like other values. In Scheme, 
functions are values, and a function can be defined anywhere—even inside another 
function. A function is defined by evaluating a new form of expression: the lambda 
expression. 

The expression 


(lambda (21 %2:-: Xn) €) 


denotes the function that takes values v1, v2,..., Un and returns the result of eval- 
uating e in an environment where x, is bound to vj, 12 is bound to v2, and so on. 
Together with the LET expressions, the lambda expression is what distinguishes 
pScheme syntax from Impcore syntax; roughly speaking, jsScheme is Impcore plus 
LET expressions, LAMBDA expressions, and S-expression data. The lambda expres- 
sion is the key to many useful programming techniques, the most important and 
widely used of which are presented in this chapter. 

By itself, lambda is not obviously powerful; one lambda is simple and innocuous. 
For example, (lambda (x y) (+ (* x x) (* y y))) denotes the function that, given 
values v and w, returns v? + w?. Its only novelty is that it is anonymous; unlike 
Impcore functions and C functions, Scheme functions need not be named. 


120b. (transcript 95a) += <120a 121ab 
-> ((lambda (x y) (+ (* x x) (* y y))) 3 4) 
25 
-> (Clambda (x y) (+ (* x x) (* y y))) 707 707) 
999698 
-> ((lambda (x y z) (+ x (+ y z))) 1 2 3) 
6 
-> ((lambda (y) (* y y)) 7) 
49 


The lambda looks like a new way of defining functions, so you might think that 
pScheme has two kinds of functions, one created with lambda and one created with 
define. But define is an abbreviation—another form of syntactic sugar. A define 
form can be desugared into a combination of val and lambda: 


(define f (21 --- Lp) e) = (val f (lambda (21 --- 2p) €)). 


As described in the sidebar on page 68, this kind of syntactic sugar is popular; 
it gives programmers a nice big language to use, while keeping the core language 
and its operational semantics (and the proofs!) small. 

The define form can be desugared into a val only because in puScheme, a func- 
tion is just another kind of value—and all values, including functions, are bound in 
the same environment (Section 2.11). In Impcore, where functions and values are 
bound in different environments, define could not be desugared into a val. 

Desugaring define into val is one way to exploit the idea that a function defined 
with lambda is just another value. Besides putting it on the right-hand side ofa val, 
what else can you do with such a function? What you can do with any other value: 


* Pass it as an argument to a function. 
* Return it from a function. 
* Store it in a global variable, using set. 


* Save it in a data structure, using cons or a record constructor. 


These capabilities can help you assess the role of any species of value in any pro- 
gramming language; if you can do all these things with a value, that value is some- 
times said to be first class. “First-class functions” is a phrase sometimes used to 
characterize Scheme and other functional languages, but it’s not quite right: what’s 
essential about Scheme is that it provides first-class, nested functions. 

To see what difference nesting makes, let’s start with a non-nested example. 
Because functions are first class, a ~Scheme function (defined with define or with 
lambda) can be passed as an argument to another function. What can the function 
that receives the argument do? All the standard things listed above, which it can 
do with any first-class value. And one more—the only interesting thing to do with a 
function: apply it. As a simple example, function apply-n-times receives a func- 
tion f, an integer n, and an argument x, and it returns the result of applying f to x 
n times: 
121a. (transcript 95a) += <120b 121b> 

-> (define apply-n-times (n f x) 
(if (= 0 n) 
x 
(apply-n-times (- n 1) f (Cf x)))) 
-> (apply-n-times 77 not #t) 
#f 
-> (apply-n-times 78 not #t) 
#t 
Applying n times is more interesting with numbers: 
121b. (transcript 95a) += <12la 122> 
-> (define twice (n) (* 2 n)) 
-> (define square (n) (* n n)) 
-> (apply-n-times 2 twice 10) 


40 

-> (apply-n-times 2 square 10) 
10000 

-> (apply-n-times 10 twice 1) 
1024 

-> (apply-n-times 10 square 1) 
1 


A function like apply-n-times is described by a handy piece of jargon: a func- 
tion that takes another function as an argument is called a higher-order function. 
The term “higher-order function” is inclusive; it also describes a function that re- 
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turns another function. Functions like twice and square, which neither take func- 
tions as arguments nor return functions as results, are called first-order functions. 

Not all higher-order functions are created equal. Some, like apply-n-times, 
could be implemented in C just as easily as in Scheme. What can’t be implemented 
in C is a function that evaluates a nested lambda expression inside its own body, 
then returns the result of that evaluation, which is called a closure. Such a function 
creates a new function anonymously, “on the fly”; the closure is the representation 
of the new function. As a toy example, function add returns a closure: 

122. (transcript 95a) += <121b 123aD 

-> (val add (lambda (x) (lambda (y) (+ x y)))) 

-> (val addi (add 1)) 

-> (addi 4) 

5 
Function add is defined by the outer lambda expression, which takes x as an argu- 
ment. It’s not so interesting. What’s interesting is inner lambda, which takes y as 
an argument: every time it is evaluated, it creates a new function. The two lambdas 
work together: when add receives argument m, it returns a function which, when it 
receives argument n, returns m + n. (Therefore, add1 is a one-argument function 
which adds 1 to its argument.) Applying add to different integers can create arbitrar- 
ily many functions. Not only (add 1) but (add 2) and (add 100) can be functions. 
Even an expression like (add (length xs)) creates a function. 

New functions can be created because (lambda (y) (+ x y)) isnested inside the 
outer lambda that defines add. Every time add is called, the inner lambda is evalu- 
ated, and in Scheme, every time a lambda expression is evaluated, a new function is 
created. In languages like Impcore and C, which don’t have lambda, a new function 
can be created only by writing it explicitly in the source code. 


2.7.1 How lambda works: Closures with mutable locations 


The expression (lambda (y) (+x y)) can be evaluated to produce more than one 
function. Such a function is represented by pairing the lambda expression with 
an environment that says what x stands for. This pair forms the closure, which 
we write in “banana brackets,” as in ( (lambda (y) (+ x y)), {x +> 1} ]). The banana 
brackets emphasize that a closure cannot be written directly using Scheme syntax; 
the closure is a value that Scheme builds from a lambda expression. A closure is 
the simplest way to implement first-class, nested functions. 

A closure is defined as a pair: code and an environment. In puScheme, the code 
is a lambda expression, but what is the environment? In Impcore, an environment 
maps a name to a value (or a function). But in Scheme, an environment maps a 
name to a mutable location. You can think of a mutable location as a box containing 
a value, which can change, or you can wear your C programmer’s hat and think of 
it as a location in memory, which the environment can point to. 

A Scheme environment maps each name to a mutable location because in a 
world where there are closures, this is the easiest way to express the way assign- 
ment (set) works. In Impcore, set simply replaces an old environment with a new 
one (and can even update the environment in place). But set can be implemented 
in this way only because no environment is ever copied. In Scheme, by contrast, 
an environment can be copied into any number of closures, and there is no easy 
way for set to update them all. Instead, when a name is assigned to, set updates 
the mutable location associated with that name. 

In the following example, set updates a mutable location that is accessible only 
from within a lambda. The inner lambda evaluates to a closure in which n points to 


a mutable location. That closure is stored in global variable ten, and every time 
ten is called, it updates n and returns the new value: 
123a. (transcript 95a) += 1122 123bp 
-> (val counter-from 
(lambda (n) 


(lambda () (set n (+ n 1))))) none 
-> (val ten (counter-from 10)) : . 
<function> First-class 
-> (ten) functions, lambda, 
11 and locations 
-> (ten) 123 
12 
-> (ten) 
13 


When ten is defined, counter-from is applied, and that application allocates a lo- 
cation ¢ to hold the value of n, which is 10. The environment in which the inner 
lambda is evaluated therefore binds n to @, and the inner lambda evaluates to the 
closure ((lambda () (set n (+n1))),{n++ @,...})), which is the value of ten.’ 
A mutable location can be shared among multiple closures, which can com- 
municate with each other by mutating it. For example, a mutable number n can be 
shared by counter and reset functions, which are stored in a counter record: 


123b. (transcript 95a) += 1123a 123¢> 
-> (record counter [step reset]) 
-> (val resettable-counter-from 
(lambda (n) ; create a counter 
(make-counter (lambda () (set n (+n 1))) 
(lambda () (set n 0))))) 


The two innermost lambda expressions refer to the same n, so that when a counter’s 
reset function is called, its step function starts over at 0. And two different appli- 
cations of resettable-counter-from refer to different n’s, so that two independent 
counters never interfere. 
A counter is stepped or reset in two steps: extract a function from the counter 

record, then apply it. 
123¢. (transcript 95a) += <1123b 123d> 

-> (val step (lambda (counter) ((counter-step counter)))) 

-> (val reset (lambda (counter) ((counter-reset counter)))) 


The double applications are easy to overlook. A function is taken from the 
counter record in an inner application, such as (counter-step counter). That 
function, which takes no parameters, is called in an outer application, such as 
(C(counter-step counter)). 
In the following transcript, two counters, hundred and twenty, count indepen- 

dently and are reset independently. 
123d. (transcript 95a) += 1123c 124aD 

-> (val hundred (resettable-counter-from 100) ) 

-> (val twenty (resettable-counter-from 20)) 

-> (step hundred) 

101 

-> (step hundred) 

102 

-> (step twenty) 

21 


7 As suggested by the ellipsis, the environment contains other bindings, but the only bindings that 
affect computation are the binding of n to @ and of + to a location containing the primitive addition 
function. 
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Resetting hundred doesn’t affect twenty. 
124a. (transcript 95a) += <1123d 124b> 
-> (reset hundred) 
0 
-> (step hundred) 
1 
-> (step twenty) 
22 


The mutable n that the step and reset function share is an example of shared 
mutable state. Shared mutable state isn’t new; it’s available in any language that has 
mutable global variables. But the shared mutable state provided by lambda is more 
flexible and better controlled than a global variable. 


+ It’s more flexible because the amount of shared mutable state isn’t limited by 
the number of global variables. 


+ It’s better controlled because not every piece of code has access to it—the 
only code that has access is code that has the relevant variables in a closure. 


The mutable state that is stored in a closure is private to a function but also per- 
sistent across calls to that function. Private, persistent mutable state is sometimes 
provided as a special language feature, usually called “own variables.” An own vari- 
able is local to a function, but its value is preserved across calls of the function. 
The name comes from Algol 60, but own variables are also found in C, where they 
are defined using the keyword static. 

As another example of private, persistent mutable state, I define a simple 
random-number generator. It’s a higher-order function that takes a next function 
as parameter, and it keeps a private, mutable variable seed, which is initially 1: 
124b. (transcript 95a) += 124a 124c> 

-> (define mk-rand (next) 
(let ([seed 1]) 
(lambda () (set seed (next seed))))) 


Parameter next can be any function that takes a number and returns another num- 
ber. To make a good random-number generator requires a function that satisfies 
some sophisticated statistical properties. A simple approximation uses the linear 
congruential method (Knuth 1981, pp. 9-25) on numbers in the range 0 to 1023: 


124¢. (transcript 95a) += <124b 124d> 
-> (define simple-next (seed) (mod (+ (* seed 9) 5) 1024)) 


This generator is not, in any statistical sense, good. For one thing, after generating 
only 1024 different numbers, it starts repeating. But it’s usable: 


124d. (transcript 95a) += 124c 125b> 
-> (val irand (mk-rand simple-next) ) 
-> (irand) 
14 
-> (irand) 
131 
-> (irand) 
160 
-> (val repeatable-irand (mk-rand simple-next)) 
-> (repeatable-irand) 
14 
-> (irand) 
421 


8Technically a generator of pseudorandom numbers. 


Function irand has its own private copy of seed, which only it can access, and 
which it updates at each call. And function repeatable-irand, which might be 
used to replay an execution for debugging, has its own private seed. So it repeats 
the same sequence [1, 14, 131, 160, 421, . . .] no matter what happens with irand. 
: : §2.7 
2.7.2 Useful higher-order functions Language III: 
First-class 
functions, lambda, 
and locations 


The lambda expression does more than just encapsulate mutable state; lambda 
helps express and support not just algorithms but also patterns of computation. 
What a “pattern of computation” might be is best shown by example. 

One minor example is the function mk-rand: it can be viewed as a pattern that 125 
says “if you tell me how to get from one number to the next, I can deliver an entire 
sequence of numbers starting with 1.” This pattern of computation, while handy, 
is not used often. More useful patterns can make new functions from old functions 
or can express common ways of programming with lists, like “do something with 
every element.” Such patterns are presented in the next few sections. 


Composition 


One of the simplest ways to make a new function is by composing two old ones. 
Function 0 (pronounced “circle” or “compose”) returns the composition of two one- 
argument functions, often written f og. Composition is described by the algebraic 
law (f o g)(x) = f(g(x)), and like any function that makes new functions, it re- 
turns a lambda: 
125a. (predefined j1Scheme functions 96a) += 1106c 126c> 
(define o (f g) (lambda (x) (f (g x)))) i (Co f g) x) = (fF (g x)) 
Function composition can negate a predicate by composing not with it: 
125b. (transcript 95a) += 124d 125¢> 
-> (define even? (n) (= 0 (mod n 2))) 
-> (val odd? (o not even?)) 
-> (odd? 3) 


-> (odd? 4) 


In large programs, function composition can be used to improve modularity: an al- 
gorithm can be broken down into functions that are connected using composition. 


Currying and partial application 


A lambda can be used to change the interface to a function, as in the example of hundred 123d 
: mod B 
adu'(page122): reset 123c 
125¢. (transcript 95a) += 125b 126aD step 123¢ 
-> (val add (lambda (x) (lambda (y) (+ x y)))) twenty 123d 


Function add does what + does, but add takes one argument at a time, whereas 
+ takes both its arguments at once. For example, (add 1) is a function that adds 
1 to its argument, while (+ 1) is an error. Similarly, (+ 1 2) is 3, while (add 1 2) is 
an error. But add and + are really two forms of the same function; they differ only in 
the way they take their arguments. The forms are named: add is the curried form, 
and + is the uncurried form. The names honor the logician Haskell B. Curry. 

Any function can be put into curried form; the curried form simply takes its 
arguments one at a time. If it needs more than one argument, it takes the first 
argument, then returns a lambda that expects the remaining arguments, also one 
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at atime. As another example, the curried form of the list3 function uses three 

lambdas: 

126a. (transcript 95a) += 1125¢ 126b> 
-> (val curried-list3 (lambda (a) (lambda (b) (lambda (c) (list3 a b c))))) 
-> (curried-list3 'x) 


<function> 

-> ((curried-list3 'x) 'y) 
<function> 

-> (((curried-list3 'x) 'y) 'z) 
(x y Z) 


Curried functions don’t mesh well with Scheme’s concrete syntax. Defining one 
requires lots of lambdas, and applying one requires lots of parentheses.” If currying 
is so awkward, why bother with it? To get partial applications. A curried function is 
partially applied when it is applied to only some of its arguments, and the resulting 
function is saved to be applied later. If the function’s arguments are expected in the 
right order, partial applications can be quite useful. For example, the curried form 
of < can be partially applied to 0, and the resulting partial application takes any m 
and says whether 0 < m: 
126b. (transcript 95a) += <1126a 126d> 

-> (val <-curried (lambda (n) (lambda (m) (< n m)))) 
-> (val positive? (<-curried 0)) 
-> (positive? 0) 


tf 
-> (positive? 8) 
#t 
-> (positive? -3) 
tf 


Functions needn’t always be curried by hand. Any binary function can be con- 
verted between its uncurried and curried forms using the predefined functions 
curry and uncurry: 
126c. (predefined juScheme functions 96a) += <1125a 129> 

(define curry (f) (lambda (x) (lambda (y) (f x y)))) 
(define uncurry (f) (lambda (x y) ((f x) y))) 


126d. (transcript 95a) += 126b 126eD 
-> (val zero? ((curry =) 0)) 
-> (zero? 0) 


#t 

-> (val addi ((curry +) 1)) 
-> (add1 4) 

5 


Functions curry and uncurry obey these algebraic laws: 


(CCcurry f) x) y) = (f xy) 
(Cuncurry f) xy) = ((f x) y) 


As can be proved using the laws, the two functions are inverses; for example, if I 
curry +, then uncurry the result, I get + back again: 
126e. (transcript 95a) += 126d 127ap 
-> (val alsot+ (uncurry (curry +))) 
-> (also+ 1 4) 
5 


°More recently developed functional languages, like Standard ML, OCaml, and Haskell, use notations 
and implementations that encourage currying and partial application, so much so that in OCaml and 
Haskell, function definitions produce curried forms by default. For partial application in Scheme, see 
the proposal by Egner (2002). 


If currying makes your head hurt, don’t panic—I expect it. Both currying and 
composition are easier to understand when they are used to make functions that 
operate on values in lists. 


2.8 PRACTICE III: HIGHER-ORDER FUNCTIONS ON LISTS 


If higher-order functions embody “patterns of computation,” what are those pat- 
terns? The patterns you're best equipped to appreciate are patterns of computation 
on lists. Some of the most popular and widely reused patterns can be described in- 
formally as follows: 


* Pick just some elements from a list. 

* Make a new list from an existing list by transforming each element. 
* Search a list for an element. 

* Check every element of a list to make sure it is OK. 


* Visit every list element, perform a computation there, and accumulate a re- 
sult. Or more loosely, “do something” to every element of a list. 


These patterns, and more besides, are embodied in the higher-order functions 
filter, map, exists?, all?, and foldr, all of which are in zScheme’s initial ba- 
sis. (If you've heard of Google MapReduce, the Map is the same, and Reduce is a 
parallel variant of foldr.) 


2.8.1 Standard higher-order functions on lists 


Function filter takes a predicate p? and a list xs, and it returns a new list consist- 
ing of only those elements of xs that satisfy p?: 
127a. (transcript 95a) += <126e 127b> 
-> (define even? (x) (= (mod x 2) 0)) 
-> (filter even? '(12 3456/7 8 9 10)) 
(2 4 6 8 10) 


As requested in Exercise 27, function filter can be used to define a concise version 
of the remove-multiples function from Section 2.3.4. 

Function filter must receive a predicate as its first argument, but map works 
with any unary function; (map f xs) returns the list of results formed by applying 
function f to every element of list xs. 
127b. (transcript 95a) += 127a 128ap 

-> (map addl '(3 4 5)) 

(45 6) 

-> (map ((curry +) 5) '(3 4 5)) 

(8 9 10) 

-> (map (lambda (x) (* x x)) '(123456789 10)) 
(1 4 9 16 25 36 49 64 81 100) 

-> (primes<= 20) 

(235 7 11 13 17 19) 

-> (map ((curry <) 10) (primes<= 20)) 

C#f #f #f HF Ht #t #t #t) 

Functions filter and map build new lists from the elements of old ones— 
a common pattern of computation. Another common pattern is linear search. 
In pzScheme, linear search is implemented by two functions, exists? and all1?. 
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Each takes a predicate, and as you might expect, exists? tells whether there is an 
element of the list satisfying the predicate; al1? tells whether they all do. 


128a. (transcript 95a) += <127b 128b> 
-> (exists? even? '(12 3456/7 8 9 10)) 
#t 
-> (all? even? '(12 34567 849 10)) 
#f 
-> (all? even? (filter even? '(12 34567 89 10))) 
#t 


-> (exists? even? (filter (o not even?) '(123 4567 89 10))) 
tf 


When called on the empty list, an important “corner case,” exists? and all? 
act like the mathematical 4 and V. 


128b. (transcript 95a) += <1128a 128¢> 
-> (exists? even? '()) 
#f 
-> (all? even? '()) 
#t 

Higher-order functions on lists can make programs wonderfully concise, be- 
cause they relieve you from writing the same patterns of recursion over and over 
again. Writing common recursions in a concise, standard way helps not just the 
person who writes the code but also the people who read it. A reader who sees a 
recursive function has to figure out what is called recursively and how it works. 
But one who sees map, filter, or exists? already knows how the code works. 

Avery general pattern of recursion is to combine the car ofa list with the results 
of a recursive call. This pattern is embodied in the higher-order function foldr. 
Function foldr expects a combining operator (a two-argument function), which 
Til call @; a starting value, which I’ll call N; and a list of values, which I’ll call vs. 
Using ©, foldr combines (“folds”) all the values from vs into 8. For example, if @ 
is +, Nis 0, and vs is a list of numbers, then (foldr @ XN vs) is the sum of the list of 
numbers. 

The general case of foldr is most easily understood when written using infix 
notation. I'll write (6 x y) asx@y and (cons v vs) as v:: vs. In this notation, if vs 
has the form vq :: Vg i:+++2: Uni: 'Q, then (foldr @ & vs) isvy Bve@--- Puy, BON. 
In effect, every cons is replaced with @, and '() is replaced with X. 

Whatif & is not associative? The rin foldr means that & associates to the right. 
The right operand of © is always either N or the result of applying a previous @: 


(foldr BN "(vy va-++ Un)) = 01 @ (v2 (+++ S (Un PN))). 


Function foldr has a companion function, fold1, in which & associates to the 
left, and 8 is combined with v1, not with v,,. Because each result becomes a right 
operand of ®, fold1 is effectively foldr operating on a reversed list: 


(foldl @N "(v1 vV2-++ Un)) = Un © (Un-1 @ (+ ® (v1 ®N))). 


For example, (foldl - 0 '(123 4)) is (4—(3—(2—(1—0)))) = 2. Onthe same 
list, (foldr - 0 '(1234)) is (1 — (2— (8 — (4—0)))) = -2. 


128¢. (transcript 95a) += 128b 13lap 
-> (foldl - © '(1 2 3 4)) 
2 
-> (foldr - © '(1 2 3 4)) 
-2 


More applications of foldr and fold] are suggested in Exercises 8, 29, and 30. 


2.8.2 Visualizations of the standard list functions 


Which list functions should be used when? Functions exists? and all? are not 
hard to figure out, but map, filter, and foldr can be more mysterious. They can 
be demystified a bit using pictures, as inspired by Harvey and Wright (1994). 


A generic list xs can be depicted as a list of circles: 52.8 


Si Se OY. OO GA Practice III: 
Higher-order 


If f is a function that turns one circle into one triangle, as in (f CQ) = A, then ! ; 
functions on lists 


(map f xs) turns a list of circles into a list of triangles. 


xs = ©. 010-0. 6 0 129 
(map fxs) = AN 


If p? is a function that takes a circle and returns a Boolean, asin (p? ()) = , then 
(filter p? xs) selects just some of the circles: 


xs Se OS CPOE) oe EO) 
(filter p?xs) = © Cp © ~ O 
Finally, if f is a function that takes a circle and a box and produces another box, 
asin (f O[_]) = then (fold f[_]|xs) folds all of the circles into a single box: 
xs = Ly De Cs se ea UE) 


————— 


| 


The single box can contain any species of value—even another sequence of circles. 


(foldr f XS) = 


2.8.3 Implementations of the standard list functions 


Most of the higher-order list functions are easy to implement and easy to under- 


stand. Each is a recursive function with one base case (which consumes the empty all? B 130 
list) and one induction step (which consumes a cons cell). All are part of the ini- Gx 127a 
tial basis of zScheme. Except for app, they are described by the algebraic laws in sae : ee 
Figure 2.4 on the following page. foldr B131 


Function filter is structured in the same way as function remove-multiples 
from chunk 102b; the only difference is in the test. Filtering the empty list produces 
the empty list. In the induction step, depending on whether the car satisfies p?, 
filter may or may not cons. 

129. (predefined juScheme functions 96a) += <1126c 130a> 
(define filter (p? xs) 
(if (null? xs) 
'O 
(if (p? (car xs)) 
(cons (car xs) (filter p? (cdr xs))) 
(filter p? (cdr xs))))) 


(filter p? '()) 
(filter p? (cons y ys)) 
(filter p? (cons y ys)) 
(map f '()) 

(map f (cons y ys)) 
(exists? p? '()) 


(exists? p? (cons y ys)) 
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130 


(all? p? (cons y ys)) 


(foldr combine zero '()) 


(foldr combine zero (cons y ys)) 


(foldl combine zero '()) 


(foldl combine zero (cons y ys)) 


='() 

= (cons y (filter p? ys)), when (p? y) 
= (filter p? ys), when (not (p? y)) 
sO) 

(cons (f y) (map f ys)) 

= #f 

= #t, when (p? y) 

= (exists? p? ys), when (not (p? y)) 


= #t 

= (all? p? ys), when (p? y) 

= #f, when (not (p? y)) 

= zero 

= (combine y (foldr combine zero ys)) 
= zero 


= (foldl combine (combine y zero) ys) 


Figure 2.4: Algebraic laws of pure higher-order functions on lists 


Function map is even simpler. There is no conditional test; the induction step 
just applies f to the car, then conses. 


130a. (predefined j1Scheme functions 96a) += 


(define map (f xs) 
(if (null? xs) 
me) 


1129 130b> 


(cons (f (car xs)) (map f (cdr xs))))) 


Function app is like map, except its argument is applied only for side effect. 
Function app is typically used with printu. Because app is executed for side ef- 


fects, its behavior cannot be expressed using simple algebraic laws. 


130b. (predefined puScheme functions 96a) += 


(define app (f xs) 
(if (null? xs) 
tf 


<1130a 130c> 


(begin (f (car xs)) (app f (cdr xs))))) 


Each of the preceding functions processes every element of its list argument. 
Functions exists? and all? don't necessarily do so. 
the moment it finds a satisfying element; all? stops the moment it finds a non- 


satisfying element. 


130c. (predefined juScheme functions 96a) += 


(define exists? (p? xs) 
(if (null? xs) 
tf 
(if (p? (car xs)) 
#t 
(exists? p? (cdr xs))))) 
(define all? (p? xs) 
(if (null? xs) 
#t 
(if (p? (car xs)) 
(all? p? (cdr xs)) 
#f))) 


<130b 131bp> 


Function exists? stops 


Function all? could also be defined using De Morgan’s law, which says that 
=Va.P(x) = Jx.4P(x). Negating both sides gives this definition: 


131a. (transcript 95a) += 1128c 131c> 
-> (define alt-all? (p? xs) (not (exists? (0 not p?) xs))) 
-> (alt-all? even? '(123 4567 8 9 10)) 


-> (alt-all? even? '()) 


-> (alt-all? even? (filter even? '(12 3456/7 8 9 10))) 


Finally, foldr and foldl, although simple, are not necessarily easy to under- 
stand. Study their algebraic laws, and remember that (car xs) is always a first 
argument to combine, and zero is always a second argument. 
131b. (predefined puScheme functions 96a) += <1130¢c 

(define foldr (combine zero xs) 
(if (null? xs) 
zero 
(combine (car xs) (foldr combine zero (cdr xs))))) 
(define foldl (combine zero xs) 
(if (null? xs) 
zero 
(foldl combine (combine (car xs) zero) (cdr xs)))) 


2.9 PRACTICE IV: HIGHER-ORDER FUNCTIONS FOR POLYMORPHISM 


A function like filter doesn’t need to know what sort of value predicate p? is ex- 
pecting. For example, filter can be used with function even? to select elements of 
alist of numbers; or it can be used with function (0 even? alist-pair-attribute) 
to select elements of an association list that contains symbol-number pairs; or 
it can be used with infinitely many other combinations of predicates and lists. 
The ability to be used with arguments of many different types makes filter poly- 
morphic (see sidebar on the next page). Functions exists?, all1?, map, foldl, and 
foldr are also polymorphic. By contrast, a function that works with only one type 
of argument, like <, is monomorphic. Polymorphic functions are especially easy to 
reuse. In this section, polymorphism is demonstrated in examples that implement 
set operations and sorting. 

As shown in chunks 105a and 105c above, set operations can be implemented 
using recursive functions. But they can be made more compact and (eventually) 
easier to understand by using the higher-order functions exists?, curry, and 
foldl. 


131c. (transcript 95a) += 131a 133ap 
-> (val emptyset '()) 
-> (define member? (x s) (exists? ((curry equal?) x) s)) 
-> (define add-element (x s) (if (member? x s) s (cons x S))) 
-> (define union (si s2) (foldl add-element si s2)) 


-> (define set-of-list (xs) (foldl add-element '() xs)) 
-> (set-of-list '(a bc x y a)) 

(y x c b a) 

-> (union '(1 2 3 4) '(2 4 6 8)) 

(8 6 12 3 4) 


These set functions work on sets of atoms, and because member? calls equal?, 
they also work on sets of lists of atoms. But they won't work on other kinds of sets, 
like sets of sets or sets of association lists; equal? is too pessimistic. 
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cons P $313d 
curry B 126 
equal? B 104 
even? 127a 
filter B 129 
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Three kinds of polymorphism 


When programmers can say “code reuse” with a fancy Greek name, they sound 
smart. What’s less smart is that at least three different programming techniques 
are all called “polymorphism.” 


* The sort of polymorphism we find in the standard list functions is called 
parametric polymorphism.* In parametric polymorphism, the polymor- 
phic code always executes the same algorithm in the same way, regard- 
less of the types of the arguments. Parametric polymorphism is the sim- 
plest kind of polymorphism, and although it is most useful when com- 
bined with higher-order functions, it can be implemented without spe- 
cial mechanisms at runtime. Parametric polymorphism is found in some 
form in every functional language. 


* Object-oriented languages such as Smalltalk (Chapter 10) enjoy another 
kind of polymorphism, which is called subtype polymorphism. In subtype 
polymorphism, code might execute different algorithms when operating 
on values of different types. For example, in a language with subtype 
polymorphism, squares and circles might be different types of geomet- 
ric shapes, but they might both implement draw functions. However, the 
circle would draw differently from the square, using different code. Sub- 
type polymorphism typically requires some sort of object or class system 
to create the subtypes; examples can be found in Chapter 10. 


* Finally, in some languages, a single symbol can stand for unrelated func- 
tions. For example, in Python, the symbol + is used not only to add num- 
bers but also to concatenate strings. A number is not a kind of string, 
and a string is not a kind of number, and the algorithms are unrelated. 
Nonetheless, + works on more than one type of argument, so it is consid- 
ered polymorphic. This kind of polymorphism is called ad hoc polymor- 
phism, but Anglo-Saxon people tend to call it overloading. It is described, 
in passing, in Chapter 9. 


In object-oriented parts of the world, “polymorphism” by itself usually means 
subtype polymorphism, and parametric polymorphism is often called generics. 
But to a dyed-in-the-wool functional programmer, generic programming means 
writing recursive functions that consume types.’ If you stick with one crowd 
or the other, you'll quickly learn the local lingo, but if your interests become 
eclectic, you'll want to watch out for that word “generic.” 


“The word “parametric” might look like it comes from a function’s parameter or from passing 
functions as parameters. But the polymorphism is called “parametric” because of type parameters, 
which are defined formally, as part of the language Typed juScheme, in Chapter 6. 

>You are not expected to understand this. 


To address the issue, let’s focus on sets of association lists. Two association lists 
are considered equal if they each have the same keys and attributes, regardless of 
how the key-attribute pairs are ordered. In other words, although an association list 
is represented in the world of code as a sequence of key-attribute pairs, what it stands 
for in the world of ideas is a set of key-value pairs. Therefore, two association lists 
are equal if and only if each contains all the key-value pairs found in the other: 


133a. (transcript 95a) += 131c 134c> 

-> (define sub-alist? (al1 ale2) 

; all of all's pairs are found in al2 

(all? (lambda (pair) 

(equal? (alist-pair-attribute pair) 
(find (alist-pair-key pair) al2))) 
al1)) 

-> (define =alist? (all al2) 

(and (sub-alist? ali al2) (sub-alist? ale ali))) 
-> (salist? '() 'Q)) 


-> (=alist? '((E coli) (I Magnin) (U Thant)) 
"(CE coli) (I Ching) (U Thant))) 


-> (salist? '((U Thant) (I Ching) (E coli)) 
'((E coli) (I Ching) (U Thant))) 
#t 


Function =alist? makes it possible to implement sets of association lists, but 
it doesn’t dictate how. The wrong way to do it is to write a new version of member? 
which uses =alist? instead of equal?; it could be called al-member?. Then be- 
cause add-element calls member?, we would need a new version of add-element, 
which would use al-member? instead of member?. And so on. The wrong path leads 
to a destination at which everything except emptyset is reimplemented. And then 
if anyone wants sets of sets, all the operations have to be reimplemented again. 
The destination is a maintainer’s hell, where there are several different implemen- 
tations of sets, all using nearly identical code and all broken in the same way. For 
example, the implementation above performs badly on large sets, and if better per- 
formance is needed, any improvement has to be reimplemented N times. Instead 
of collecting monomorphic implementations of sets, a better way is to use higher- 
order functions to write one implementation that’s polymorphic. 


2.9.1 Approaches to polymorphism in Scheme 


In Scheme, polymorphic set functions can be implemented in three styles. All 
three use higher-order functions; instead of using equal?, the set functions use 
an equality predicate that is stored in a data structure or passed as a parameter. 
The style is identified by the location in which the predicate is stored: 


* In the simplest style, a new parameter, the equality predicate my-equal?, 
is added to every function. The modified functions look like this: 


133b. (polymorphic-set transcript 133b)= (S320c) 134a> 
-> (define member? (x s my-equal?) 
(exists? ((curry my-equal?) x) s)) 
member? 
-> (define add-element (x s my-equal?) 
(if (member? x s my-equal?) s (cons x s))) 
add-element 


Passing an equality predicate to every operation, asin (member? x s equal?) 
or (add-element x s =alist?), is the responsibility of the client code. That’s 
a heavy burden. Client code must keep track of sets and their equality pred- 
icates, and it must ensure the same equality predicate is always passed with 
the same set, consistently, every time. 
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* This burden can be relieved by storing a set’s equality predicate with its ele- 
ments. In the second style, a set is represented by a record with two fields: 
an equality predicate and a list of elements. 


134a. (polymorphic-set transcript 133b) += (S320c) <133b 134b> 
-> (record aset [eq? elements]) 
-> (val emptyset (lambda (my-equal?) (make-aset my-equal? '()))) 
-> (define member? (x s) 
(exists? ((curry (aset-eq? s)) x) (aset-elements s))) 
-> (define add-element (x s) 
(if (member? x s) 
Ss 
(make-aset (aset-eq? s) (cons x (aset-elements s))))) 


For sets of association lists, these operations are used as follows: 


134b. (polymorphic-set transcript 133b) += (S320c) <1134a 
-> (val alist-empty (emptyset =alist?)) 
-> (val s (add-element '((U Thant) (I Ching) (E coli)) alist-empty)) 
(make-aset <function> (((U Thant) (I Ching) (E coli)))) 
-> (val s (add-element '((Hello Dolly) (Goodnight Irene)) s)) 
(make-aset <function> (((Hello Dolly) (Goodnight Irene)) ((U Thant)... 
-> (val s (add-element '((E coli) (I Ching) (U Thant)) s)) 
(make-aset <function> (((Hello Dolly) (Goodnight Irene)) ((U Thant)... 
-> (member? '((Goodnight Irene) (Hello Dolly)) s) 
#t 


The best feature of this style is that a predicate is supplied only when con- 
structing an empty set. 


The second style imposes embarrassing run-time costs. Each set must con- 
tain the equality predicate, which adds extra memory to each set, and which 
requires a level of indirection to gain access either to the equality predicate 
or to the elements. The second style also imposes a lesser but still nontrivial 
burden on client code, which has to propagate the equality predicate to each 
point where an empty set might be created. 


In the third style, these issues are addressed by storing the equality predi- 
cate in the operations. Each operation is represented by a closure, and the 
equality function is placed the environment of that closure. In this style, no 
extra memory is added to any set, a set’s elements are accessed without in- 
direction, and the equality predicate is cheaper to fetch from a closure than 
it would be from a set. And client code has to supply each equality predicate 
only once, to create the specialized operations that work with that predicate. 


In a third-style implementation of sets, the equality predicate is placed into 
closures by function set-ops-with, which returns a record of set operations. 
Each operation is specialized to use the given equality. 
134. (transcript 95a) += 1133a 135a> 
-> (record set-ops [member? add-element]) 
-> (define set-ops-with (my-equal?) 
(make-set-ops 
(lambda (x s) (exists? ((curry my-equal?) x) s)) ; member? 
(lambda (x s) ; add-element 
(if (exists? ((curry my-equal?) x) s) s (cons x s))))) 


Specialized operations for a set of association lists are created by applying 
set-ops-with to predicate =alist?. 


135a. (transcript 95a) += <1134c 135b> 
-> (val alist-set-ops (set-ops-with =alist?)) 
-> (val al-member? (set-ops-member? alist-set-ops)) 
-> (val al-add-element (set-ops-add-element alist-set-ops)) 


These operations can be used without mentioning the equality predicate. 
135b. (transcript 95a) += <135a 135¢> 
-> (val emptyset '()) 
-> (val s (al-add-element '((U Thant) (I Ching) (E coli)) emptyset)) 
(CCU Thant) (I Ching) (E coli))) 
-> (val s (al-add-element '((Hello Dolly) (Goodnight Irene)) s)) 
(((Hello Dolly) (Goodnight Irene)) (CU Thant) (I Ching) (E coli))) 
-> (val s (al-add-element '((E coli) (I Ching) (U Thant)) s)) 
(((Hello Dolly) (Goodnight Irene)) (CU Thant) (I Ching) (E coli))) 
-> (al-member? '((Goodnight Irene) (Hello Dolly)) s) 
#t 


2.9.2 Polymorphic, higher-order sort 


Another widely used, polymorphic algorithm is sorting. Good sorts are tuned for 
performance, and when code is tuned for performance, it should be reused. Anda 
sort function can be reused in the same way as the set functions: just as sets require 
an equality function that operates on set elements, sorting requires a comparison 
function that operates on list elements. So like the set operations, a sort function 
should take the comparison function as a parameter. For example, the polymor- 
phic, higher-order function mk-insertion-sort takes a comparison function 1t?, 
and returns a function that sorts a list of elements into nondecreasing order (ac- 
cording to function 1t?). The algorithm is from chunk 101a. 
135¢. (transcript 95a) += <135b 135d> 
-> (define mk-insertion-sort (1t?) 
(letrec ([insert (lambda (x xs) 
(if (null? xs) 
(list1 x) 
(if (1t? x (car xs)) 
(cons x xs) 
(cons (car xs) (insert x (cdr xs))))))] 
[sort (lambda (xs) 
(if (null? xs) 
'O 
(insert (car xs) (sort (cdr xs)))))]) 
sort)) 


This definition includes our first example of letrec, which is like let, but which 
makes each bound name visible to all the others. Internal functions sort and 
insert are both recursive, and because both are defined in same letrec, either 
one can also call the other. 

Function mk-insertion-sort makes sorting flexible and easy to reuse. For ex- 
ample, when used with appropriate comparison functions, it can make both in- 
creasing and decreasing sorts. 
135d. (transcript 95a) += <1135¢ 137a> 

-> (val sort-increasing (mk-insertion-sort <)) 
-> (val sort-decreasing (mk-insertion-sort >)) 
-> (sort-increasing '(6 9174385 2 10)) 
(123456789 10) 

-> (sort-decreasing '(6 9174385 2 10)) 
(109876543 e 1) 
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Function mk-insertion-sort implements the same pattern of computation as 
mk-rand, only more useful: “if you tell me when one element should come before 
another, I can sort a list of elements.” It can equally well sort lists by length, sort 
pairs lexicographically, and whatever else you need. That’s the power of higher- 
order, polymorphic functions. 


2.10 PRACTICE V: CONTINUATION-PASSING STYLE 


In the examples above, higher-order functions use lambda to capture data in a clo- 
sure. Such data may include counters, predicates, equality tests, comparison func- 
tions, and more general functions. Using these functions as data doesn’t really af- 
fect the control flow of our computations; for example, no matter what comparison 
function is passed to insertion sort, the insertion-sort code executes in the same 
way. But higher-order functions can also be used for control flow. A function call 
is used in the same way that a C programmer or an assembly-language program- 
mer might use a goto: to transfer control and never come back. A function used in 
this way is called a continuation. And a continuation is even more powerful than a 
goto, because a continuation can take arguments!?° 

As an initial example, continuations can be used to represent the exits from a 
computation. To develop the example, let’s return to association lists. As noted in 
Section 2.3.8, find has a little problem: it cannot distinguish between a key that 
is bound to '() and a key that, like milk in the aisle, is not bound at all. Solving 
this problem requires a change in the interface. One possibility is to change only 
the value returned. For example, as in full Scheme, find could return a key-value 
pair if it finds the key and #f if it finds nothing. Or like Lua, it could always return 
a pair, one element of which would say if it found anything and the other element 
of which would be what it found. But the conditional logic required to tests these 
kinds of results can be annoying. 

A more flexible alternative is to pass two continuations to the find routine: one 
to tell the find routine what to do next (“how to continue”) if it succeeds, and one 
in case of failure. That is, when (find-c k alist succ fail) is called, one of two 
things must happen. If key k is found in al, then find-c calls succ with the associ- 
ated value. If k is not found, find-c calls fail with no arguments: 


(find-c k alist succ fail) = (succ v), when (find k alist) = v; 
(find-c k alist succ fail) = (fail), otherwise. 


The code looks like this: 
136. (definition of find-c 136)= (137a) 
(define find-c (key alist success-cont failure-cont) 
(letrec 
({search (lambda (alist) 
(if (null? alist) 
(failure-cont) 
(if (equal? key (alist-first-key alist)) 
(success-cont (alist-first-attribute alist)) 
(search (cdr alist)))))]) 
(search alist))) 


Your teachers probably hated goto. Maybe they considered it harmful. Or maybe they didn’t even 
tell you about goto—trying to find goto in an introductory programming book can be like trying to find 
Trotsky in a picture of early Soviet leaders. If you’ve been unfairly deprived of goto, Knuth (1974) can 
remedy the injustice. 


As an example, find-c can be used to code a “pair-or-symbol” response: 


137a. (transcript 95a) += 135d 137b> 
-> (definition of find-c 136) 
-> (find-c 'Hello '((Hello Dolly) (Goodnight Irene) ) 
(lambda (v) (liste 'the-answer-is v)) 
(lambda () 'the-key-was-not-found) ) 


(the-answer-is Dolly) $2.10 
-> (find-c 'Goodbye '((Hello Dolly) (Goodnight Irene)) Practice Vs 
(lambda (v) (list2 'the-answer-is v)) Continuation- 
(lambda () 'the-key-was-not-found) ) passing style 
the-key-was-not-found 137 
More usefully, find-c can implement a table with a default element. 
137b. (transcript 95a) += <137a 137¢> 
-> (define find-default (key table default) 
(find-c key table (lambda (x) x) (lambda () default))) 
Before going deeper into continuations, let’s exercise find-default. 
Function find-default can be used to count frequencies of words, using atable 
with default value zero. The table maps each word to the number of times it occurs, 
and it’s used in function freq, which finds the frequencies of all the words in a 
list and lists the most frequent first. In freq, words are visited by foldr, which is 
passed add, which looks up a word’s count in the table and increases the count by 1. 
137c. (transcript 95a) += <1137b 137d> 
-> (define freq (words) 
(let 
({add (lambda (word table) 
(bind word (+ 1 (find-default word table 0)) table))] 
[sort (mk-insertion-sort 
(lambda (p1 p2) (> (cadr p1) (cadr p2))))]) 
(sort (foldr add '() words)))) 
-> (freq '(it was the best of times , it was the worst of times ! )) 
((it 2) (was 2) (the 2) (of 2) (times 2) (best 1) (, 1) (worst 1) (! 1)) 
add-element 131c 
As another example, find-default can help find out what words follow another AIG RS 
word. (Statistics about sequences of words are sometimes used to characterize au- attribute 
thorship.) This time, the table maps each word to a set containing the words that eo . 
follow it; the default element is the empty set. Because the follow-set function op- Pay 
erates on more than one word at atime, a foldr would be a bit hard to read; instead, bind B 106 
the code defines an auxiliary recursive function, walk: cadr B96 
137d. (transcript 95a) += 1137c 138> Be f Be 
-> (define followers (words) equal? B 104 
(letrec foldr B131 
({add (lambda (word follower table) list2 B% 
(bind word mk-insertion- 
(add-element follower (find-default word table '())) sort 135¢ 
table))] null? P 162a 


[walk (lambda (first rest table) 
(if (null? rest) 
table 
(walk (car rest) 
(cdr rest) 
(add first (car rest) table))))]) 
(walk (car words) (cdr words) '()))) 
-> (followers '(it was the best of times , it was the worst of times ! )) 
(Cit (was)) (was (the)) (the (worst best)) (best (of)) (of (times)) ... 
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The answer doesn't fit on the page, so let’s show just the words that are followed by 
more than one word. They can be selected by using the curried form of filter to 
accept only elements that have more than one word in their cadr. 
138. (transcript 95a) += 137d 142b> 
-> (define more-than-one? (xs) 
(if (null? xs) #f (not (null? (cdr xs))))) 
-> (val multi-followers 
(0 
(Ccurry filter) (lambda (p) (more-than-one? (cadr p)))) 
followers) ) 
-> (multi-followers 
‘(it was the best of times , it was the worst of times ! )) 
((the (worst best)) (times (! ,))) 
-> (multi-followers 
"(now is the time for all good men to come to the aid of the party)) 
((the (party aid time)) (to (the come))) 


2.10.1 Continuation-passing style and direct style 


A function like find-c is said to be written in continuation-passing style: not only 
does it take continuations as arguments, but it can return only what the continua- 
tions return.'! Continuation-passing style is easily identified by looking at a func- 
tion’s algebraic laws: if every right-hand side is a call to a parameter, the func- 
tion is written in continuation-passing style. Continuation-passing style can also 
be identified by looking at the code: a function written in continuation-passing 
style ends either by calling a continuation or by calling another function written in 
continuation-passing style (including itself). 

A function written in continuation-passing style is inherently polymorphic: the 
type of its result is whatever the continuations return, and if it’s given different 
continuations, it can return values of different types. When the function is defined 
but not yet used, the continuations are not yet known, so the type of the result isn’t 
yet known. But that type is still useful to refer to, so it is referred to abstractly as 
the answer type. The answer type can help you design appropriate continuations; 
for example, in find-default, the answer type is the type of default, but it is also 
the type of (lambda (x) x) applied to a value in table—so the type of default must 
be the same as the types of the values in table. 

Unlike find-c, find-default is not written in continuation-passing style: it 
does not take any continuations, soit cannot return the result of calling one. A func- 
tion like find-default is written in direct style. Direct style is usually easier to un- 
derstand, but continuation-passing style is more flexible and powerful. 


2.10.2 Continuations for backtracking 


When it succeeds or fails, find-c exits. But continuations can also more sophis- 
ticated control flow, like the ability to backtrack on failure. In direct-style imper- 
ative code, backtracking is hard to get right, but using continuations and purely 
functional data structures, it’s easy. And a backtracking problem can demonstrate 
the virtues of leaving the answer type unknown. 

One classic problem that can be solved with backtracking is Boolean satisfac- 
tion. The problem is to find an assignment to a collection of variables such that a 
Boolean formula is satisfied, that is, a satisfying assignment. This problem has many 


Properly speaking, continuation-passing style is a representation of programs in which all func- 
tions, even primitive functions, end by transferring control to a continuation (Appel 1992). 


applications, often in verifying the correctness of a hardware or software system. 
For example, on a railroad, if the signals are obeyed, no two trains should ever be 
on the same track at the same time, and this property can be checked by solving a 
very large Boolean-satisfaction problem. 

The satisfaction problem can be simplified by considering only only formu- 
las in conjunctive normal form. (General Boolean formulas are the subject of Exer- 
cise 41.) A conjunctive normal form is a conjunction of disjunctions of literals: 


CNF ::= Di \ D2 A---A Dy conjunction, 
D n= 1, VloV--+VIm disjunction, 
l n=a| ae literal. 
The x is a metavariable that may stand for any Boolean variable. 

A CNF formula is satisfied if all of its disjunctions D; are satisfied, and a dis- 
junction is satisfied if any of is literals |; is satisfied. A literal x is satisfied if x is 
true; a literal -2 is satisfied if x is false. A formula be satisfied by more than one 
assignment; for example, the formula x V y V z is satisfied by 7 of the 8 possible as- 
signments to x, y, z. Satisfying assignments can be found by a backtracking search. 
Because the satisfaction problem is NP-hard, a search might take exponential time. 

The search algorithm presented below incrementally improves an incomplete 
assignment. An incomplete assignment associates values with some variables— 
all, none, or some number in between. An incomplete assignment is represented 
by an association list in which each key is the name of a variable and each value is 
#t or #f. A variable that doesn’t appear in the list is unassigned. 

Given disjunction D; and an incomplete assignment cur, the search algorithm 
tries to extend cur by adding variables in such a way that D; is satisfied. If that 
works, the algorithm continues by trying to extend the assignment to satisfy D;+1. 
But if it can’t satisfy D;, the algorithm doesn’t give up; instead it backtracks to Dj_1. 
Maybe D;_, can be satisfied in a different way, such that it becomes possible to 
satisfy D;. Asan example, suppose D; = x V yV z, and the search algorithm finds 
the assignment {x +> #t, y > #f, z+ #f}, which satisfies it. If Dp = ~rV y V z, 
the search has to go back and find a different assignment to satisfy D,. The search 
can be viewed as a process of going back and forth over the D,’s, tracing a path 
through this graph: 


start continue continue continue finish 
+> | -—————————_» ——>] [-————_> 
solve Dj solve Dy ee solve Dy 
_—————ooo| oo | 
backtrack backtrack backtrack 


The graph is composed of solvers that look like this: 


start succeed 
-—_£_—_—_> 
solver 
lp 
fail resume 


Thanks to the graph structure, a solver can just tackle an individual D; without 
keeping track of what it’s supposed to do afterward. Its future obligations are stored 
in two continuations, succeed and fail, which it receives as parameters. The third 
continuation in the diagram, written as resume, is the failure continuation for the 
next solver: if the next solver can't succeed, it calls resume to ask the current solver 
to try something else. 

The graph structure and its continuations are used to solve formulas in all three 
forms: CNF, D, and |. Each form is solved by its own function. For example, 
a CNF formula D, A --- A Dy is solved by a function that receives the formula, 
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an incomplete assignment cur, and continuations succeed and fail. When the 
solver is called, as represented above by the arrow labeled “start,” it acts as follows: 


+ If cur cannot possibly satisfy the first disjunction Dj, call fail with no pa- 
rameters. 


* If cur can satisfy Dj, or if it can be extended to satisfy D,, then compute 


Scheme, the (possibly extended) satisfying solution, and pass it to succeed. In addi- 
S-expressions, and tion, because D; might have more than one solution, also pass resume, which 

first-class functions succeed can call if it needs to backtrack and try an alternative solution. 
140 To make this story precise requires precise specifications of the solver functions 


and of a representation of formulas. 

The representation of CNF, the set of formulas in conjunctive normal form, 
is described by the following equations, which resemble the recursion equations 
in Section 2.5.8: 


CNF = LIST(D), 
D= LIST(LITs), 
LIT = SYM U { (list2 'not x) | 2 e€ SYM }. 


In conjunctive normal form, the symbols / and V are implicit. The — symbol is 
represented explicitly using the Scheme symbol not. 

In the code, the forms are referred to by names ds, lits, and lit. Assignments 
and continuations are also referred to by conventional names: 


ds A list of disjunctions in CNF 

lits A list of literals in D 

lit A single literal in LIT, 

cur A current assignment (association list) 
fail A failure continuation 


succeed A success continuation 


A failure continuation takes no arguments and returns an answer. A success con- 
tinuation takes two arguments—an assignment and a failure continuation—and re- 
turns an answer. 

Each of the three solver functions is written in continuation-passing style. 


* Calling (find-cnf-true-assignment ds cur fail succeed) tries to extend 
cur to an assignment that satisfies the list of disjunctions ds. 


* Calling (find-D-true-assignment lits cur fail succeed) tries to extend 
cur to an assignment that satisfies any literal in the list lits. 


* Calling (find-lit-true-assignment lit cur fail succeed) tries to extend 
cur to an assignment that satisfies literal lit. 


Each function calls succeed on success and fail on failure. The specifications can 
be made precise using algebraic laws. 

The laws for any given solver function depend on what species of formula the 
function solves. Each species is solved by a different algorithm, which depends on 
how a formula in the species is satisfied. For example, a CNF formula is satisfied 
if all its disjunctions are satisfied. There are two cases: 


* If there are no disjunctions, then cur trivially satisfies them all. And when 
cur is passed to succeed, nothing else can be done with an empty list of dis- 
junctions, so the resumption continuation is fail. 


* If there is a disjunction, it should be solved by calling the solver for disjunc- 
tions: find-D-true-assignment. Ifthat call fails, nothing more can be done, 
soits failure continuation should be fail. Butif that call succeeds, the search 
needs to continue by solving the remaining disjunctions. So the CF solver 
creates a new continuation to be passed as the success continuation. The 


new continuation calls find-cnf-true-assignment recursively, and if the §2.10 
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(find-cnf-true-assignment '() cur fail succeed) ) = (succeed cur fail) 
(find-cnf-true-assignment (cons dds) cur fail succeed)) = 
(find-D-true-assignment d cur fail 


(lambda (cur' resume) (find-cnf-true-assignment ds cur' resume succeed) ) ) 


The flow of control is characteristic of continuation-passing style: in the nonempty 
case, only the disjunction solver knows whether d can be solved, but it’s the CNF 
solver that decides what to do—and that decision is embodied in the continuations 
that are passed to the disjunction solver. 

The disjunction solver works in almost the same way, except that a disjunction 
is satisfied if any one of its literals is satisfied. So in the nonempty case, the roles of 
the success and failure continuations are reversed: if a literal succeeds, the solver 
succeeds, but if a literal fails, the solver must try the other literals. 


(find-D-true-assignment '() cur fail succeed) ) = (fail) 
(find-D-true-assignment (cons lit lits) cur fail succeed)) = 
(find-lit-true-assignment lit cur 
(lambda () (find-D-true-assignment lits cur fail succeed) ) 


succeed) 


You might be concerned that if the first literal is solved successfully, the later lit- 
erals will never be examined, and some possible solutions might be missed. But 
those later literals lits are examined by the failure continuation that is passed to 
find-lit-true-assignment, which is eventually passed to succeed as a resump- 
tion continuation. If anything goes wrong downstream, that resumption continu- 
ation is eventually invoked, and it calls (find-D-true-assignment lits ---). 
The last of the three solver functions solves a literal. It needs to know what 

variable appears in a literal and what value would satisfy the literal. 
141a. (utility functions for solving literals 141a)= 141b> 

-> (define variable-of (lit) 

(if (symbol? lit) 
lit 
(cadr lit))) cadr B%6 
-> (define satisfying-value (lit) find-c 136 
(symbol? lit)) ; #t satisfies 'x; #f satisfies '(not x) symbol? P 162a 
Because an ordinary literal is a symbol and a negated literal is a list like (not x), 
the value that satisfies a literal 1it is always equal to (symbol? lit). 
A literal is satisfied if and only if the current assignment binds the literal’s vari- 

able to a satisfying value. The test uses find-c with a Boolean answer type. 
141b. (utility functions for solving literals 141a) += <141a 142a> 

-> (define satisfies? (alist lit) 

(find-c (variable-of lit) alist 
(lambda (b) (= b (satisfying-value lit))) 
(lambda () #f))) 


The last solver function, find-lit-true-assignment, succeeds either when 
the current assignment already satisfies its literal, or when it can be made to sat- 
isfy the literal by adding a binding. There is at most one way to succeed, so the 
resumption continuation passed to succeed is always fail. 


(find-lit-true-assignment lit cur fail succeed) = (succeed cur fail), 


when cur satisfies lit 


Scheme, (find-lit-true-assignment lit cur fail succeed) = (succeed (bind x ucur) fail), 
S-expressions, and when z is lit’s variable, cur does not bind x, and 1it is satisfied by {a +> v} 
first-class functions (find-lit-true-assignment lit cur fail succeed) = (fail), otherwise 
142 To determine that cur does not bind z, the solver function uses find-c with yet 


another pair of continuations: 
142a. (utility functions for solving literals 141a) += <141b 
-> (define binds? (alist lit) 
(find-c (variable-of lit) alist (lambda (_) #t) (lambda () #f))) 

All three solver functions are coded in Figure 2.5 on the facing page. And they 
can be used with different continuations that produce answers of different types. 
For example, the CNF solver can be used to tell whether a formula is satisfiable, to 
produce one solution, or to produce all solutions. To see if a formula has a solution, 
use find-cnf-true-assignment with a success continuation that returns #t anda 
failure continuation that returns false: 
142b. (transcript 95a) += 1138 142c> 

-> (define satisfiable? (formula) 
(find-cnf-true-assignment formula '() 
(lambda () #f) 
(lambda (cur resume) #t))) 


As an example, the formula 
(1VyV2z)A (FeV ayV az) A (a Vy V 72) 


has a solution. 

142c. (transcript 95a) += <1142b 142d> 
-> (val sample-formula '((x y z) ((not x) (not y) (not z)) (x y (not z)))) 
-> (satisfiable? sample-formula) 
#t 


To actually solve a formula, use a success continuation that returns cur: 
142d. (transcript 95a) += 1142c 142e> 
-> (define one-solution (formula) 
(find-cnf-true-assignment formula '() 

(lambda () 'no-solution) 
(lambda (cur resume) cur))) 

-> (one-solution sample-formula) 

((x #t) Cy #f)) 


This formula is satisfied if x is true and y is false; the value of z doesn’t matter. 

To find all solutions, use a success continuation that adds the current solution 
to the set returned by resume. (To avoid adding duplicate solutions, cur is added 
using al-add-element, not cons.) The failure continuation returns the empty set. 
142e. (transcript 95a) += <1142d 143b> 

-> (define all-solutions (formula) 


(find-cnf-true-assignment 
formula 
me) 
(lambda () emptyset) 
(lambda (cur resume) (al-add-element cur (resume) )))) 


14a. (solver functions for CNF formulas 143a)= 
-> (define find-lit-true-assignment (lit cur fail succeed) 
(if (satisfies? cur lit) 
(succeed cur fail) 
(if (binds? cur lit) 
(fail) 
(let ([new (bind (variable-of lit) (satisfying-value lit) cur)]) 
(succeed new fail))))) 
-> (define find-D-true-assignment (literals cur fail succeed) 
(if (null? literals) 
(fail) 
(find-lit-true-assignment (car literals) cur 
(lambda () (find-D-true-assignment 
(cdr literals) cur fail succeed)) 
succeed) )) 
-> (define find-cnf-true-assignment (disjunctions cur fail succeed) 
(if (null? disjunctions) 
(succeed cur fail) 
(find-D-true-assignment (car disjunctions) cur fail 
(lambda (cur' resume) 
(find-cnf-true-assignment 
(cdr disjunctions) cur' resume succeed) )))) 


Figure 2.5: The three solver functions 


There are 9 distinct solutions, which is too many to show. 


143b. (transcript 95a) += 
-> (val answers (all-solutions sample-formula)) 
-> (length answers) 
9 


<142e 143c> 


Is there a solution in which x and y are both false? Both true? 


148c. (transcript 95a) += <1143b 143d> 
-> (exists? 
(lambda (cur) (and (= #f (find 'x cur)) (= #f (find 'y cur)))) 
answers) 
tf 
-> (exists? 
(lambda (cur) (and (= #t (find 'x cur)) (= #t (find 'y cur)))) 
answers) 
#t 


It appears that x and y can be true at the same time, but not false at the same time. 
Not all formulas have solutions. Most obviously, formula x /—z has no solution. 
143d. (transcript 95a) += 


-> (one-solution '((x) ((not x)))) 
no-solution 


1143c 164cD> 


Both the solver and find-c demonstrate that a function written in continuation- 
passing style can often be used in different ways, simply by passing it different 
continuations with different answer types. 
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135a 
and B 
bind B 106 
car P 162a 
cdr P 162a 


emptyset 105a 
exists? 6130 


find B 106 
find-c 136 
length 98 


null? P 162a 
satisfies? 141b 
satisfying-value 
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2.11 OPERATIONAL SEMANTICS 


The operational semantics of Scheme resembles the operational semantics of 
Impcore. And it uses the same techniques—an abstract machine, a big-step evalu- 
ation judgment, inference rules, and so on. But Impcore and pScheme treat envi- 
ronments differently: 


* Impcore uses three environments, which bind functions, global variables, 
and formal parameters, respectively. jsScheme uses a single environment p, 
which binds all names. 


* InImpcore, environments bind names to values. In jzScheme, environments 
bind names to mutable locations, and SET changes the contents of a location, 
not a binding in an environment. The contents of locations are modeled by 
an explicit store 0, which is a function from locations to values; think of it as 
the machine’s memory. 


* In Impcore, environments are never copied, so when the semantics says a 
name is rebound, the implementation can mutate the relevant environment 
data structure. In jsScheme, an environment is copied every time a lambda is 
evaluated, so it isn’t safe to mutate an environment data structure. Instead, 
the implementation builds an extended environment with a new binding. 


pScheme’s semantics assumes there is an infinite supply of fresh locations; 
a fresh location ¢ is allocated by writing ¢ ¢ dom. In Section 2.12, this allocation 
judgment is implemented using malloc, which has only a finite supply of locations. 
In Chapter 4, the allocation judgment is implemented using a more sophisticated 
allocator, which creates the illusion of an infinite supply by reusing old locations. 

In Scheme, an abstract machine evaluating an expression e in environment p 
is in state (e, 0,0). The evaluation judgment takes the form (e,p,0) |) (v,o’). 
This judgment says two things: 


* The result of evaluating expression e in environment p, when the state of the 
store is o, is the value v. 


* The evaluation may update the store to produce a new store o’. 


Evaluating an expression never changes an environment; at most, evaluating an 
expression can change the store. Therefore, the right-hand side of an evaluation 
judgment does not need a new environment p’. 

Evaluation never copies a store a, and when a rule makes a new store 0’, it dis- 
cards the old store. Therefore each store is used exactly once; such a store is called 
single-threaded or linear. The store is designed that way because a single-threaded 
store can be implemented efficiently: when a rule calls for a new store, the imple- 
mentation does not have to build one; instead, it mutates the previous store. 


2.11.1 Abstract syntax and values 


LScheme’s abstract syntax is straightforward. It has the definitions and expressions 
of Impcore, plus LETX and LAMBDAX expressions. And APPLY can apply arbitrary 
expressions, not just names. 


144, (ast.t144)= 145ap 
Def* VAL (Name name, Exp exp) 


| EXP (Exp) 
| DEFINE (Name name, Lambda lambda) 


14a. (ast.t 144) += 4144 
Exp* = LITERAL (Value) 


VAR (Name) 
SET (Name name, Exp exp) 
IFX (Exp cond, Exp truex, Exp falsex) 


WHILEX (Exp cond, Exp body) 

BEGIN (Explist) 

APPLY (Exp fn, Explist actuals) 

LETX (Letkeyword let, Namelist xs, Explist es, Exp body) 
LAMBDAX (Lambda) 


Definitions of Value and Lambda are shown with the interpreter (Section 2.12); type 

Letkeyword is defined here. 

145b. (type definitions for Scheme 145b)= (S318a) 152b> 
typedef enum Letkeyword { LET, LETSTAR, LETREC 3 Letkeyword; 

A uScheme value is a symbol, number, Boolean, empty list, cons cell, clo- 
sure, or primitive function. These values are written SYMBOL(s), NUMBER(7), 
BOOLV(b), NIL, PAIR((), 2), (LAMBDA((71,...,2n),e), 9), and PRIMITIVE(p). 
The corresponding data definition is shown with the interpreter (Section 2.12). 


2.11.2 Variables and functions 


The most interesting parts of the semantics are the rules for lambda, let, and func- 
tion application. The key ideas involve mutable locations: 


* Each variable refers to a location. To examine or change a variable, we must 
first look up its name in p (to find its location), then look at or change the 
contents of the location (which means looking at o or producing a new 0’). 


* Let-bindings allocate fresh locations, bind them to variables, and initialize 
them. 


* Function application also allocates fresh locations, which hold the values of 
actual parameters. These locations are then bound to the names of the for- 
mal parameters of the function being applied. 


Variables 


The single environment makes it easy to look up the value of a variable. Lookup 
requires two steps: p(x) to find the location in which z is stored, and o(p()) to 
fetch its value. In a compiled system, these two steps are implemented at different 
times. At compile time, the compiler decides in what location to keep x. At run 
time, a machine instruction fetches a value from that location. 

Looking up a variable doesn’t change the store a. 


zéeédomp p(x) € dome 
(vaR(x), p,0) 4) (a(p(x)),¢) 


Assignment translates the name into a location, then changes the value in that 
location, producing a new store. The evaluation of the right-hand side may also 
change the store, from a to 0’. 


(VAR) 


redomp p(x) =£ _(e,p,0)  (v,0") 
(SET(x,€),p,0) 4} (v,a'{£ +> v}) 
12In Scheme, two variables never refer to the same location. If x and y did refer to the same location, 


then when x was mutated, y would change. This behavior is called “aliasing,” and it makes compiler 
writers miserable. ;uScheme variables cannot alias (Exercise 51). 


(ASSIGN) 
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The threading of the store is subtle; the conclusion must extend o’, not oc. If the 
conclusion were to extend a, the semantics would be saying that changes made by e 
should be undone. This behavior would surprise the programmer, and it would 
force the implementor to save a copy of the old o and then reinstate it after the 
evaluation of e. At considerable expense. 


Let, let*, and letrec 


A LET expression evaluates all the right-hand sides, then binds the names to the re- 
sulting values, and finally evaluates its body in the resulting environment. Nothing 
is added to the environment p until all the right-hand sides have been evaluated. 


Y1,...,%y all distinct 
l1,...,4n ¢ domo, (and all distinct) 
09 =O 


(€1,p; a0) 1 (v4, o1) 


(Ens P) On—1) V (Un; On) 


(e, p{a1 > €1,...,An > Ln}, onf{lr O u1,..., ln Un}) | (vu, 0°) (Ler) 
(LET((21, €1,-++-5,Un, En), e), P; o) 1 (v, a’) 
Locations ¢,,..., @, are not only fresh but also mutually distinct. 


By contrast, a LETSTAR expression binds the result of each evaluation into the 
environment immediately. The action is revealed by the subscripts on p. 


po =p 00 =o 
(€1, Po, 90) V (v1, 00) 41 €domog pr = po{t1 > 1} 01 = oO{41 + vi} 


(€n, Pn—1;On—1) al, (Un; On—1) 
ln € domoy_1 Pn = pn—-1f{2n ln} on = on_1fln Un} 
(e, Pn, On) V (v, 0") 
(LETSTAR((21,€1,---,2n,€n),€),P, 0) 4 (v, 0’) 


(LETSTAR) 

Finally, LETREC binds the locations into the environment before evaluating the 

expressions, so that references to the new names are valid in every right-hand side, 
and the names stand for the new locations, not for any old ones. 


l1,...,4n ¢ domo (and all distinct) 
Y1,..-,2y all distinct 
e; has the form LAMBDA(---), 1 <<i<n 
p' = play > b1,...,%n bn} 
do = o{f; + unspecified, ..., 2, 4 unspecified} 
(e1, 0’, 70) 4 (v1,01) 


(€n; 0’; On—1) 1 (Un, On) 
(e, p!, On{ ly > U1,-.-,Ln 2 Un}) | (vu, 0") 
(LETREC((21,€1,---,;Un;€n),€), 2,0) 4 (v, 0") 


(LETREC) 


The contents of ¢;,..., @;, are not specified until after all the e1,..., €, have been 
evaluated; informally, the e,’s are evaluated with the x,’s bound to new, uninitial- 
ized locations. Until the locations are initialized, using them is unsafe; using a lo- 
cation that contains “unspecified” is an unchecked run-time error. For safety, as in 
full Scheme, the evaluation of every e; must be independent of the value of any x, 


and it also must not mutate any x;. In other words, evaluating e; must neither read 
nor write the contents of any location ¢;. To guarantee that evaluating e; does not 
read or write any locations, wScheme insists that each e; be a LAMBDA expression. 


Function abstraction; function application; statically scoped closures 


Functional abstraction wraps the current environment, along with a lambda ex- 
pression, in a closure. LAMBDA copies the current environment. It is because en- 
vironments can be copied that they map names to locations, not values; otherwise 
different closures could not share a mutable location. (One example of such shar- 
ing is the “resettable counter” in Section 2.7.1.) 


L1,..-,%y all distinct 
(LAMBDA((11,..-,2n),€), 2,0) 4 ((LAMBDA((11,...,2n),e),p),o) 

(MKCLOSURE) 

When a closure (LAMBDA((X1,...,2%n),€c),Pc|) is applied, the body of the 

function, e€., is evaluated using the environment in the closure, p., which is ex- 

tended by binding the formal parameters to fresh locations ¢1,..., &,. These loca- 

tions are initialized with the values of the actual parameters; afterward, the body 
can change them. 


£1,...,€n € dom oy (and all distinct) 


(e, p,0) |) ((LAMBDA((21,.-.,%n),€c); Pc), Oo) 
(€1, P, Fo) 1 (v1,01) 


(En Py-On-1) 1 (Un, On) 
om PlX1 1 by, 6.65 En Pe erka 4 U1, ..., bn Un }) 4 (v, a’) 
(APPLY(€, €1,---,€n),P,0) 4 (v, 07) 


(APPLYCLOSURE) 
The APPLYCLOSURE rule closely resembles the APPLYUSER rule used in Impcore. 
The crucial differences are as follows: 


* In Scheme, the function to be applied is designated by an arbitrary expres- 
sion, which must evaluate to a closure. In Impcore, the function is desig- 
nated by aname, which is looked up in ¢ to find a user-defined function. Both 
a Scheme closure and an Impcore user-defined function contain formal pa- 
rameters anda function body, but only the closure contains the all-important 
environment p-, which stores the locations of the variables mentioned in the 
body.’? In Impcore, no such environment is needed; every function is de- 
fined at top level, so every variable is either a formal parameter or can be 
found in the global environment €. 


In u~Scheme, the parameters are added not to the empty environment but to 
the environment p, stored in the closure. And like let-bound names, the 
formal parameters are bound to fresh locations, not directly to values. 


As in Impcore, the evaluation of e, is independent of the environment p of the 
calling function, so a zScheme function behaves the same way no matter where it 
is called from. (Also as in Impcore, the evaluation is not independent of the store a 
at the point of the call, so when mutable state is involved, a wScheme function may 


13In my implementation, the environment binds all variables that are in scope, not just those that 
are mentioned in the body of the lambda expression. Such promiscuous binding could use memory 
unnecessarily, and it could add to the expense of applying the closure. For details, see Exercise 19 on 
page 299 in Chapter 4 and Exercise 10 on page 325 in Chapter 5. 
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behave differently when called at different times, even when called from the same 
place in the source code. A good example is the counter-stepping function from 
Section 2.7.1.) 

The APPLYCLOSURE rule describes an implementation of first-class, nested 
functions called statically scoped closures. The “closure” part you know about; “stat- 
ically scoped” means that the meanings of the variables (scope) are determined by 
the compile-time (static) context in which the code appears—those variables are 
either bound in the global environment or are bound by statically enclosing lets 
and lambdas. Because static scoping is determined by properties of the text, it is 
sometimes also called lexical scoping. As an example of local reasoning about a 
static context, a programmer (or an implementation of Scheme) who encounters 
an expression like (lambda (x) (+ x y)) can discover what y is simply by searching 
“outward” for a let or lambda that binds y. The search stops at the enclosing def- 
inition, which is at top level; if the search reaches top level without finding a let 
binding or lambda binding for y, then y must be bound in the global environment 
by a val or define. 


Dynamic scoping: An alternative to static scoping Closures are an innovation of 
Scheme; they were not part of original Lisp. Original Lisp represented every func- 
tion as a bare LAMBDA expression with formal parameters and a body, in much the 
same way as Impcore represents a user-defined function. This representation ad- 
mits of a very simple implementation, which never has to copy an environment. 
Original Lisp treated LAMBDA as a value, using the following rule for function ab- 
straction. 


(LAMBDA((1,-.-,2n),€), 9,0) 4} (LAMBDA((21,...,2%n),€),0) 
(LAMBDA for original Lisp) 


Original Lisp applied a function by evaluating its body in the environment of its 
caller, extended with bindings of formal parameters: 


C1,...,;4n ¢ domo, (and all distinct) 


(e, P; o) 1 (LAMBDA((1, eivae Pays a) oo) 
(e1, P; do) a (v1, o1) 


(nk P; On—1) a (Un; on) 
(€c, p{®1 > 1,...,¢n > ln}, onf{hlr O U1,..-,Ln Unt) Ye (u, 0") 
(APPLY(€, €1,---,€n),p,0) ¥ (v, 0’) 
(APPLYLAMBDA for original Lisp) 
This rule is much easier to implement than Scheme’s rule, but it makes lambda 
much less useful; in original Lisp, higher-order functions that contain inner 
lambdas, like o and curry, don't work as expected. 

To find the location of a free variable, an implementation of original Lisp looks 
at the calling function, and its caller, and so on. The context in which a function 
is called is a dynamic property, and the original rule is a form of dynamic scoping. 
Dynamic scoping came about because McCarthy didn’t realize that closures were 
needed; when the original behavior was called to his attention, he characterized the 
semantics as a bug in the Lisp interpreter. Scheme’s static scoping was widely seen 
as an improvement, and in the 1980s, static scoping was adopted in Common Lisp. 
If you want to experiment with a language that has dynamic scoping, try Emacs 
Lisp. Some interesting examples are presented by Abelson and Sussman (1985, 
pp. 321-325). 


Formal parameters in an independent environment 


Function application takes the environment in a closure and extends it with bind- 
ings for formal parameters: 


P{X1 > U1,-.-,2n > Un}. 


The idea is that formal parameters hide outer variables of the same name. To ex- 
press that idea formally, formal parameters can be placed in an environment of 
their own: pp = {1 +> U1,...,%n_ + Up}. The two environments can then be 
combined using a + symbol: p, + pf. The combined environment, in which the 
body of the function is evaluated, obeys the following laws: 


dom(p. + pr) = dom p, U dom pr, 


_ f pp(x), when € dom py 
(Pe + ps)(x) = { pc(@), whena ¢ dom pr. 


To look for x in a combined environment, we look first in p, and only if we don't 
find it do we look in p;. That is, pr hides p,. Combined environments start to shine 
when there are more of them; for example, in Smalltalk-80, the body of a method 
is evaluated in an environment that combines class variables, instance variables, 
formal parameters, and local variables. 


2.11.3 Rules for other expressions 


The rules for evaluating the other expressions of jsScheme are very similar to the 
corresponding rules of Impcore. 
As in Impcore, a literal value evaluates to itself without changing the store. 


(LITERAL) 


(LITERAL(v), p,0) 4} (v,o) 


Conditionals, loops, and sequences are evaluated as in Impcore, except that 
falsehood is represented by BOOLV(#f), not 0. 


(Cis P; o) a (v1, a’) U1 x BOOLV(#f) (e2, P; a’) a (v2, a”) 


{UF(ex, €2,€3), 9.0) F W2,0") an 
(e1,p.0) 4 (o1.0") m1 =Roorv(#t) —(es,p.0") 1 (00) Garang 
(IF(e1, €2, €3); Pp; o) (v3, a”) 
(e1,P,0) 4 (v1,0’) uv, # BOOLV(#F) 
(€2, Ps a’) ay (v2, a”) (WHILE(€1, €2), P; oa”) 4 (v3, oa!) (WHILEITERATE) 
(WHILE(€1, €2), P; a) 1 (v3, ol) 
(e1, 9,0) 4. (v1,0’) vy = BOOLV(#f) 
(WHILE(€1, €2), 2,0) 1} (BOOLV(#f), 0’) ETE) 
(BEGIN(), p,c) |) (BOOLV(#f), c) Mera BEGINY 
(e1,p,90) 4 (v1, 01) 
(€2,p,01) 4 (v2, 02) 
(ens Ps On—1) ay (Un; On) (BEGIN) 


(BEGIN(€1, €2,---,€n);P;70) 4 (Un; On) 


§2.11 
Operational 
semantics 


149 


Primitives 


Of jsScheme’s many primitives, only a few are presented here. 


Arithmetic Primitive arithmetic operations obey the same rules as in Impcore, 
but they have to be notated differently: in Impcore, every value is a number, but 
in Scheme, only a value of the form NUMBER(n) is a number. As in Chapter 1, 


Scheme addition serves as a model for all the arithmetic primitives. 
ee and (e, p, 00) 4 (PRIMITIVE(+), 71) 
first-class functions (e1, 9,01) | (NUMBER(n), o>) 
150 (€2, Pp; 2) ay (NUMBER(7), 73) 


APPLYADD 
(APPLY(e, €1, €2), P, 00) 4) (NUMBER(n + m), 73) ( ) 


Equality Testing for equality is a bit tricky. Primitive function = implements a 
relation v = v’, which is defined by these rules: 


m = n (identity of numbers) 


(EQNUMBER) 
NUMBER(n) = NUMBER(m) 
= ‘(i ity of 1 
$8 = 8 (identity of symbols) (EQSYMBOL) 
SYMBOL(s) = SYMBOL(s’) 
b = U’ (identity of Booleans) 
EQB 
BOOLV(b) = BOOLV(’) eo 
(EQNIL) 


NIL = NIL 
The complementary relation is written v # v’; it holds if and only if there is no 
proof of v = v’. Itis worth noting that PAIR((), 02) # PAIR(¢1, 2). That is, cons 
cells never compare equal, even when they are identical. 
The behavior of primitive equality is defined using relations = and #. 


(e, P, 00) |) (PRIMITIVE(=), 01) 
(e1,p,01) 4 (v1, ¢2) 


(eo, P; 02) (v2, 03) 
U1 = v2 


APPLYEQTRUE 
(APPLY (€, €1, €2), P, Jo) ) (BOOLV(#t), 73) ( . ) 
(e, P, 00) 4} (PRIMITIVE(=), 71) 
(e1, p, 01) (v1, 02) 
(€2, p, 02) |) (v2, a3) 
V1 £ Ve (i.e., no proof of v; = v2) (APPLYEOFALSE) 


(APPLY(€, €1, €2), P, Jo) ) (BOOLV(#F), 73) 
Printing Asin Impcore, the operational semantics takes no formal notice of print- 
ing, so the semantics of print1n are those of the identity function. 
(€, P, 00) 4} (PRIMITIVE(println), 01) 


(e1, P; 01) V (v, 72) 
(APPLY(e€, €1),P,00) | (v,02) — while printing v 


(APPLYPRINTLN) 


Primitive print1n has the same semantics as print, but printu has a more restric- 
tive semantics: it is defined only when the code point is a suitable number. 


(e, P, 00) 4} (PRIMITIVE(printu), 1) 
(€1, P, 01) 4) (NUMBER(7), 02) 
0<n< 26 


APPLY e€, e€ ; Ps 00 NUMBER(n > 02 while printing the UTF-8 coding of n 


List operations The primitive CONS builds a new cons cell. The cons cell is a pair 
of locations that hold the values of the car and cdr. 


(e, P, 00) 4} (PRIMITIVE(cons), 01) 
(e1, 0,01) 4 (v1, 02) 
(€2, P, 02) V (v2, 03) 
é, ¢ domas lo ¢ doma3 lL, # bo 
(APPLY(€, €1, €2), P, 70) 4) (PAIR (C1, C2), 03{ 61 +4 U1, £2 + v2}) 


(CONS) 


Primitives car and cdr observe cons cells. 


(e, P, 00) ) (PRIMITIVE(car), 01) 
(e1, 0,01) 4) (PAIR(C1, €2), 72) 
(APPLY(e, €1), 0,0) | (72(41), 72) 


(CAR) 


(e, P, 00) ) (PRIMITIVE(cdr), 01) 
(e1, P,01) ¥ (PAIR (EC), £2), 2) 
(APPLY(e€, €1), 2,00) 4) (a2(l2), 02) 
If the result of evaluating e; is not a PAIR, rules CAR and CDR do not apply, and the 


abstract machine gets stuck. In such a case, my interpreter issues a run-time error 
message. 


(CDR) 


2.11.4 Rules for evaluating definitions 


A definition typically adds a new binding to the environment and changes the store. 
Its evaluation judgment is (d, p,0) — (p’,o’), which says that evaluating defini- 
tion d in environment p with store o produces a new environment p’ and a new 
store o’. 


Global variables 


When a global variable x is bound to an expression, what happens depends on 
whether z is already bound in p. If x is bound, then VAL is equivalent to SET: the 
environment is unchanged, but the store is updated. 


x € domp 
(e,p,0) 4 (v, 0") 
WaL(e,€), po) > (0, 0{p(a) > v}) 


(DEFINEOLDGLOBAL) 


If x is not already bound, VAL allocates a fresh location @, extends the environment 
to bind x to @, evaluates the expression in the new environment, and stores the 
result in ¢: 


x¢domp ¢¢domo 


(e, p{a +> l},0{0 ++ unspecified}) |) (uv, a’) 
(vVAL(z,e), 2,0) > (p{a > ba {LH v}) 


. (DEFINENEWGLOBAL) 


The “unspecified” value stored in @ effectively means that an adversary gets to look 
at your code and choose the least convenient value. Code that depends on an un- 
specified value invites disaster, or at least an unchecked run-time error. 

Why does VAL add the binding to p before a value is available to store in £? To en- 
able a recursive function to refer to itself. To see the need, consider what would 
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happen in the following definition of factorial if the binding were not added until 
after the lambda expression was evaluated: 


(val fact 
(lambda (n) 
(if (=n 0) 
1 


(* n (fact (~ n 1)))))) 


If the binding isn’t added before the closure is created, then when the body of the 
lambda expression is evaluated, it won't be able to call fact—because the environ- 
ment saved in the closure won't contain a binding for fact. That’s why the seman- 
tics for VAL in Scheme is different from the semantics for VAL in Impcore. 


Top-level functions 
DEFINE is syntactic sugar for a VAL binding to a LAMBDA expression. 


(VAL(f, LAMBDA((i1,..-,2n),€)),p,0) + (p', a") 
(DEFINE(f, (21,---,2n),€),P,0) > (p', 0’) 


(DEFINEFUNCTION) 


Top-level expressions 
A top-level expression is syntactic sugar for a binding to the global variable it. 


(vAL(it, e), p,0) > (p', a") 


(exP(e), p,o) — (p', a’) (EVALEXP) 


2.12 THE INTERPRETER 


pScheme’s interpreter, like Impcore’s interpreter, is decomposed into modules 
that have well-defined interfaces. Modules for names and printing are reused from 
Chapter 1, as is. Because Scheme’s environments and values are different from 
Impcore’s, environment and value modules are new. And the abstract-syntax mod- 
ule is generated automatically; its representations and code are derived from the 
data definition shown in Section 2.11.1. 


2.12.1 Representation of values 


The representation of values is generated from the data definition shown here. 
The empty list is called NIL, which is its name in Common Lisp. A function is repre- 
sented by a CLOSURE, which is a Lambda with an environment; the Lambda structure 
contains the function's formal-parameter names and body. 


152a. (value.t 152a)= 
Lambda = (Namelist formals, Exp body) 


Value = SYM (Name) 
| NUM (int32_t) 
| BOOLV (bool) 
| NIL 
| PAIR (Value *car, Value *cdr) 
| CLOSURE (Lambda lambda, Env env) 
| PRIMITIVE (int tag, Primitive *function) 

152b. (type definitions for uScheme 145b) += (S318a) <145b 153a> 


typedef Value (Primitive) (Exp e, int tag, Valuelist vs); 


Table 2.6: Correspondence between juScheme semantics and code 


Semantics Concept Interpreter 
d Definition Def (page 144) 
e€ Expression Exp (page 144) 
£ Location Value * 
x Name Name (page 43) §2.12 
v Value Value (page 152) The interpreter 
p Environment Env (page 153) 153 
o Store Machine memory (the C heap) 
(e,p,0) | (v,o’) — Expression evaluation eval(e, p) = 0, 
with o updated to o’ (page 155) 
(d,p,07) > (p',o") Definitionevaluation evaldef(d, p, echo) = p’, 
with o updated to o’ (page 159) 
x € dom p Definedness find(x, p) != NULL (page 153) 
p(x) Location lookup find(x, p) (page 153) 
a(p(x)) Value lookup *find(x, p) (page 153) 
p{x rH e} Binding bindalloc (page 153) 
é¢ domo Allocation bindalloc (page 153) 
a{£H v} Store update *f=v 
Why does a Primitive take so many arguments? Shouldn't a primitive function 
just take a Valuelist and return a Value? No. Ifa primitive fails, it needs to show 
where the failure occurred; that’s the Exp e. And by using an integer tag, a single 
Primitive function can implement multiple Scheme primitives. The C function 
that implements psScheme’s arithmetic primitives, for example, makes it easy for 
those primitives to share the code that ensures both arguments are numbers. Im- 
plementations of the primitives appear in Section 2.12.5 and in Appendix L. 
2.12.2 Interfaces 
The Environment and the Store 
In the operational semantics, the store o models the memory of the abstract ma- ae 
‘ . ‘ ‘ type Name 43a 
chine. In the implementation, the store is represented by the memory of the real resene Se 
machine; a location is represented by aC pointer of type Value *. An environment 43a 
Env maps names to pointers; find(x, p) returns p(a) whenever x € dom p; when type Value A 
x € dom p, it returns NULL. type Te wae at 


153a. (type definitions for Scheme 145b) += (S318a) <152b 


typedef struct Env *Env; 


153b. (function prototypes for wScheme 153b)= 
Value *find(Name name, Env env); 


($318a) 153c> 


A location is allocated, initialized, and bound to a name in one step, by func- 
tion bindalloc. Formally, when called with store a, bindalloc(z, v, 0) chooses an 
é ¢ domo, updates the store to be o{£ ++ v}, and returns the extended environ- 
ment p{x +> ¢}. 


153c. (function prototypes for Scheme 153b) += (S318a) 4153b 154a> 
Env bindalloc (Name name, Value v, Env env); 


Env bindalloclist(Namelist xs, Valuelist vs, Env env); 
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Calling bindalloclist((1,...,2n),(U1,---, Un), P) does the same job for a list of 
values, returning p{x1 +> ¢1,...,Un +> €,}, where ¢),...,¢, are fresh locations, 
which bindalloclist initializes to values v1,...,Un. 

Although environments use a different interface from Impcore, their repre- 
sentation is unchanged. In both interpreters, an environment is represented using 
mutable state; that is, the environment associates each name with a pointer to a 
location that can be assigned to. Impcore’s interface hides the use of locations, 
but uScheme’s interface exposes them. As a result, find can do the work of both 
isvalbound and fetchval. 


Impcore [Scheme 
isvalbound(x,p) find(x,p) 4 NULL 
fetchval (a, p) *find(a, p) 


Using this interface, a zScheme variable can be mutated without using a function 
like Impcore’s bindval; code just assigns to the location returned by find. As long 
as « € dom p, bindval(, v, p) is replaced by *find(x, p) = v. Leveraging C point- 
ers and mutable locations makes jsScheme’s interface simpler than Impcore’s. 


Allocation 


The fresh locations created by bindalloc and bindalloclist come fromallocate. 
Calling allocate(v) finds a location £ ¢ domg, stores v in ¢ (thereby updating o), 
and returns @. 


154a. (function prototypes for jScheme 153b) += (S318a) 4153c 154b> 
Value *allocate(Value v); 


Allocation is described in great detail in Chapter 4. 


Values 


Values are represented as specified by the data definition in chunk 152a. For con- 
venience, values #t and #f are always available in C variables truev and falsev. 


154b. (function prototypes for Scheme 153b) += (S318a) 1154a 154c¢> 
extern Value truev, falsev; 


Values can be tested for truth or falsehood by function istrue; any value dif- 
ferent from #f is regarded as true. 


154. (function prototypes for uScheme 153b) += (S318a) <1154b 154d> 
bool istrue(Value v); 


When an unspecified value is called for by the semantics, one can be obtained 
by calling function unspecified. 


154d. (function prototypes for uScheme 153b) += (S318a) 1154 155a> 
Value unspecified(void); 


If you get the jzScheme interpreter to crash, your ppScheme code is probably looking 
at a value returned by unspecified. That’s an unchecked run-time error. 


Evaluation 


As in Impcore, the — relation in the operational semantics is implemented by 
evaldef, and the |) relation is implemented by eval. The store o is not passed 
or returned explicitly; it is represented by the C store, i.e., by the contents of 
memory. Because o is single-threaded—every store is used exactly once and then 
discarded—the semantics can be implemented by updating memory in place. 


Table 2.7: Specifications used in print and fprint 


oe 
oe 


Print a percent sign 


%d Print an integer in decimal 

%e Print an Exp 

%E Print an Explist (list of Exp) 

%\ Print a Lambda (in ASCII, the \ character is acommon proxy for \) 
%n Print a Name 

%N Print a Namelist (list of Name) 
%p  PrintaPar 

%P Print a Parlist (list of Par) 

%r Print an Env 

%s Print a char* (string) 

%t Print a Def 

%v Print a Value 

%V Print a Valuelist (list of Value) 


For example, eval(e, p), when evaluated with store o, finds av anda o’ such that 
(e, p, 7) |) (v, a’), updates the store to be o’, and returns v. 
155a. (function prototypes for j1Scheme 153b) += (S318a) «154d 


Value eval (Exp e, Env rho); 
Env evaldef(Def d, Env rho, Echo echo); 


Similarly, evaldef(e, p, echo), when evaluated with store o, finds a p’ and ao’ 
such that (e, 0,0) —> (p',o’), updates the store to be o’, and returns p’. If echo is 
ECHOING, evaldef also prints the name or value of whatever expression is evaluated 
or added to p. 


Printing 


Just like the Impcore interpreter, the wScheme interpreter uses functions print 
and fprint, but the ;sScheme interpreter knows how to print more kinds of things. 
The alternatives are shown in Table 2.7. Most of these specifications are used only 
to debug the interpreter. 


2.12.3 Implementation of the evaluator 


As in Impcore, the evaluator starts with switch, which chooses how to evaluate e 
based on its syntactic form: 


155b. (eval.c 155b)= 157¢> 
Value eval(Exp e, Env env) ¢ 
switch (e->alt) £ 
case LITERAL: (evaluate e->literal and return the result 156a) 
case VAR: (evaluate e->var and return the result 156b) 
case SET: (evaluate e->set and return the result 156c) 
case IFX: (evaluate e->ifx and return the result 159b) 
case WHILEX: (evaluate e->whilex and return the result 159c) 
case BEGIN: (evaluate e->begin and return the result 159d) 
case APPLY: (evaluate e->apply and return the result 156e) 
case LETX: (evaluate e->1etx and return the result 157d) 
case LAMBDAX: (evaluate e->lambdax and return the result 156d) 
3 


assert(Q); 
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Literals 


As in Impcore, a literal evaluates to itself. 


156a. (evaluate e->literal and return the result 156a)= (155b 48b) 
return e->literal; 


Variables and assignment 


Variable lookup and assignment are simpler than in Impcore, because jsScheme 
has only one rule for each form. 


xé€domp p(x) € dome 
(vaR(x), 9,0) 4 (o(p(x)), 0) 


xé€domp p(t)=l  (e,p,c) 1 (v,o") 
(SET(z,e), p,0) |} (vu, a’ {04 v}) 
In the code, p(x) is implemented by find(, p), and o(€) is implemented by *2. 
156b. (evaluate e->var and return the result 156b)= (155b 48b) 
if (find(e->var, env) == NULL) 
runerror("name %n not found", e->var); 
return *find(e->var, env); 


(VAR) 


(ASSIGN) 


In an assignment, the store is set to a’ {¢ ++ u} by assigning to *¢. 


156c. (evaluate e->set and return the result 156c)= (155b 48b) 
if (find(e->set.name, env) == NULL) 
runerror("set unbound variable %n in %e", e->set.name, e); 
return *find(e->set.name, env) = eval(e->set.exp, env); 


Closures and function application 


Wrapping a closure is simple: 


L1,...,2y all distinct 
(LAMBDA((1, +e fn); @); P; a) 1 ((LAMBDA((x1, na »fn), eh Pp ), a) 
(MKCLOSURE) 
156d. (evaluate e->lambdax and return the result 156d)= (155b) 
return mkClosure(e->lambdax, env); 
Formal parameters %1,...,2» are confirmed to be distinct when e is parsed, by 


function check_exp_duplicates in chunk S336c. Checking at parse time exposes 
problems right away, without waiting for bad code to be evaluated. 

When a function is applied, its actual parameters are evaluated and stored in vs. 
The next step depends on whether the function is a primitive or a closure. 


156e. (evaluate e->apply and return the result 156e)= (155b 48b) 
t 
Value f = eval (e->apply.fn, env); 
Valuelist vs = evallist(e->apply.actuals, env); 


switch (f.alt) £ 
case PRIMITIVE: 
(apply f .primitive to vs and return the result 157a) 
case CLOSURE: 
(apply f .closure to vs and return the result 157b) 
default: 
runerror("%e evaluates to non-function %v in %e", 
e->apply.fn, f, e); 


Because a primitive is represented by a pair containing a function pointer and 
a tag, its application is simpler than in Impcore. Function f. primitive. function 
gets the tag, the arguments vs, and the abstract syntax e. (The syntax is used in 
error messages.) 
157a. (apply f .primitive to vs and return the result 157a)= (156e) 

return f.primitive.function(e, f.primitive.tag, vs); 

A closure is applied by extending its stored environment (p, in the operational 
semantics) with the bindings for the formal variables, then evaluating the body in 
that environment. 


£1,...,€n € dom oy (and all distinct) 


(e, p,0) |) ((LAMBDA((21,.-.,%n),€c); Pe), Oo) 
(€1, P; 00) V (v1, 01) 


(Cn, P;) In—1) 4 (Un; On) 
(€e; Pce{X1 +> l1,..-,8n > Enh, on{Ai > U1,---,ln 2 Unt) (vu, 0") 
(APPLY(e, El,--- ,€n); Pp; a) (v, a") 


(APPLYCLOSURE) 
157b. (apply f .closure to vs and return the result 157b)= (156e) 
t 
Namelist xs = f.closure.lambda.formals; 
checkargc(e, lengthNL(xs), lengthVL(vs)); 
return eval(f.closure.lambda.body, 
bindalloclist(xs, vs, f.closure.env)); 
3 


As in Impcore’s interpreter, evallist evaluates a list of arguments in turn, re- 
turning a list of values. 
157. (eval.c 155b) += <155b 
static Valuelist evallist(Explist es, Env env) ¢ 
if (es == NULL) £ 
return NULL; 
3 else § 
Value v = eval(es->hd, env); 
return mkVL(v, evallist(es->tl, env)); 


3 
Let, let*, and letrec 


Each expression in the let family uses its internal name-expression pairs to cre- 
ate a new environment, then evaluates the body in that environment. Each form 
creates the new environment in a different way. 


157d. (evaluate e->letx and return the result 157d)= (155b) 
Switch (e->letx.let) £¢ 
case LET: (extend env by simultaneously binding es to xs 158a) 
break; 
case LETSTAR: (extend env by sequentially binding es to xs 158b) 
break; 
case LETREC: (extend env by recursively binding es to xs 159a) 
break; 
default: assert(Q); 
3 


return eval(e->letx.body, env); 


As with lambda, all names are confirmed to be distinct at parse time. 


// enforce uScheme's order of evaluation 
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bindalloclist 
153c 
checkarge 47c 
type Env 153a 
env 155b 
eval 155a 
evallist $310b 
type Explist S309b 
find 153b 
lengthNL A 
lengthVL A 
mkClosure A 


mKVL A 
type Namelist 
43a 
runerror 47a 
type Value <A 
type Valuelist 
$309c 


ALET expression evaluates its right-hand sides, then binds them all at once. All 
the work is done by functions evallist and bindalloclist. 


Y1,..-,Xy all distinct 
l1,...,4n ¢ domo, (and all distinct) 
009 =O 
(e1, p, 00) Y (v1, 01) 
Scheme, 
S-expressions, and : 
first-class functions (€nsP,On—1) (Uns On) 
(e, p{r1 meg £1, el eae tn > Gof Oar imma U1, eee? en A Dt) 4 (v, 0’) 
158 ; (LET) 
(LET((21, €1,---,Un, En), e); P; a) (v, o ) 
158a. (extend env by simultaneously binding es to xs 158a)= (157d) 


env = bindalloclist(e->letx.xs, evallist(e->letx.es, env), env); 
A LETSTAR expression binds a new name as each expression is evaluated. 


po =p 00 =o 
(e1, 00,90) 4 (v1,00) i Edomop = pr =pof{tite if or = afl vi} 


(€n; Pn-1;On-1) 4 (Uns On—1) 


Ln ¢ dom o7,—1 Pn = Pn—-1{&n = Ly} On = On-1thn > Un } 
(e, Pn, On) Ve (v, 0") 


(LETSTAR((21, E1,-+--5Un, En); €); P; o) 1 (v, a’) 
(LETSTAR) 
158b. (extend env by sequentially binding es to xs 158b)= (157d) 
£ 
Namelist xs; 
Explist es; 
for (xs = e->letx.xs, es = e->letx.es; 
XS && eS; 
xS = xs->tl, es = es->t1) 
env = bindalloc(xs->hd, eval(es->hd, env), env); 
assert(xs == NULL && es == NULL); 
3 
Finally, before evaluating any expressions, LETREC binds each name to a fresh 
location. 
f1,...,4n ¢ domo (and all distinct) 
Y1,...,2y all distinct 
e; has the form LAMBDA(---), 1 <i<n 
p! a p{x1 > Steere ad Crt 
09 = o{f; + unspecified, ...,, + unspecified} 
(e1, 0’, 00) 4 (v1, 01) 
(En, p, On-1) a (Un; On) 
€,p', Ont O V1,...,ln Ov v,o! 
( Ps nl uf 1; yin nt) VC ’ ) (LETREC) 


(LETREC((@1, €1, Pee :Eny€n), e) Ps a) 1 (v, a") 


The locations’ initial contents are unspecified, and they remain unspecified until 
all the values are computed. The right-hand sides are confirmed to be LAMBDAs at 


parse time, by the same function that confirms the x,’s are distinct, so they needn't 
be checked here. 


159a. (extend env by recursively binding es to xs 159a)= (157d) 
£ 


Namelist xs; 


for (xs = e->letx.xs; XS; xS = xs->tl) 
env = bindalloc(xs->hd, unspecified(), env); 
Valuelist vs = evallist(e->letx.es, env); 
for (xs = e->letx.xs; 
XS && VS; 
XS = xS->tl, vs = vs->t1) 
*find(xs->hd, env) = vs->hd; 
assert(xs == NULL && vs == NULL); 


Conditional, iteration, and sequence 


The control-flow operations are implemented much as they are in Impcore. The 
semantic rules are not worth repeating. 


159b. (evaluate e->ifx and return the result 159b)= 
if (istrue(eval(e->ifx.cond, env))) 
return eval(e->ifx.truex, env); 
else 


(155b 48b) 


return eval(e->ifx.falsex, env); 


159c. (evaluate e->whilex and return the result 159c)= 
while (istrue(eval(e->whilex.cond, env))) 
eval(e->whilex.body, env); 
return falsev; 


(155b 48b) 


159d. (evaluate e->begin and return the result 159d) = 


g 


(155b 48b) 


Value lastval = falsev; 

for (Explist es = e->begin; es; es = es->tl) 
lastval = eval(es->hd, env); 

return lastval; 


2.12.4 Evaluating true definitions 


Each true definition is evaluated by function evaldef, which updates the store 
and returns a new environment. If echo is ECHOES, evaldef also prints. Function 
evaldef doesn’t handle record definitions; the record form is syntactic sugar, not 
a true definition. 
159e. (evaldef.c 159e)= 
Env evaldef(Def d, Env env, Echo echo) £¢ 
switch (d->alt) ¢ 
case VAL: (evaluate val binding and return new environment 160a) 
case EXP: (evaluate expression, assign to it, and return new environment 160b) 
case DEFINE: (evaluate function definition and return new environment 160c) 


3 


assert(0); 
3 
According to the operational semantics, the right-hand side of a val binding 
must be evaluated in an environment in which the name d->val.name is bound. 
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bindalloclist 
153c 
type Def A 


type Echo S$293f 
type Env 153a 
env 155b 
eval 155a 
evallist $310b 
type Explist S309b 


falsev $327b 
find 153b 
istrue 154c 
type Namelist 

43a 
unspecified 154d 
type Value <A 
type Valuelist 

$309c 


Scheme, 
S-expressions, and 
first-class functions 


160 


If no binding is present, one is added, with an unspecified value. 


x € domp 
(e,p,0) 4 (v, 0’) 
(vaL (2, e), p,0) — (p,o'{p(x) + v}) 


(DEFINEOLDGLOBAL) 


z¢domp l¢doma 
(e, p{z + l},0{£ > unspecified}) |) (uv, 0’) 
(VAL(x,€),p,0) > (p{x H bl}, a'{£H v}) 


(DEFINENEWGLOBAL) 


160a. (evaluate val binding and return new environment 160a)= (159e) 
t 
if (find(d->val.name, env) == NULL) 
env = bindalloc(d->val.name, unspecified(), env); 
Value v = eval(d->val.exp, env); 
*find(d->val.name, env) = v; 
(if echo calls for printing, print either v or the bound name $311e) 
return env; 


3 


As in Impcore, evaluating a top-level expression has the same effect on the en- 
vironment as evaluating a definition of it, except that the interpreter always prints 
the value, never the name “it.” 


160b. (evaluate expression, assign to it, and return new environment 160b)= (159e) 
£ 
Value v = eval(d->exp, env); 
Value *itloc = find(strtoname("it"), env); 
(if echo calls for printing, print v $312a) 
if (itloc == NULL) { 
return bindalloc(strtoname("it"), v, env); 
3 else § 
*itloc = v; 
return env; 


3 
A DEFINE is rewritten to VAL. 


160c. (evaluate function definition and return new environment 160c)= (159e) 
return evaldef (mkVal(d->define.name, mkLambdax(d->define.lambda)), 
env, echo); 


2.12.5 Implementations of primitives 


Each primitive is associated with a unique tag, which identifies the primitive, and 
with a function, which implements the primitive. The tags enable one function to 
implement multiple primitives, which makes it easy for similar primitives to share 
code. The primitives are implemented by these functions: 


arith Arithmetic primitives, which expect integers as arguments 
binary Non-arithmetic primitives that expect two arguments 
unary Primitives that expect one argument 


Arithmetic primitives 


Each arithmetic primitive expects two integer arguments, which are obtained by 
projecting sScheme values. The projection function projectint32 takes not only 
a value but also an expression, so if its argument is not an integer, it can issue an 
informative error message. 
16la. (prim.c 161a)= 161b> 
static int32_t projectint32(Exp e, Value v) £ 
if (v.alt != NUM) 
runerror("in %e, expected an integer, but got %v", e, v); 
return v.num; 


3 


Function arith first converts its arguments to integers, then consults the tag 
to decide what to do. In each case, it computes a number or a Boolean, which is 
converted a jsScheme value by either mkNum or mkBool, both of which are gener- 
ated automatically from the definition of Value in code chunk 152a. Checks for 
arithmetic overflow are not shown. 
161b. (prim.c 161a) += <16la 161c> 

Value arith(Exp e, int tag, Valuelist args) { 
checkargc(e, 2, lengthVL(args)); 
int32_t n = projectint32(e, nthVL(args, 0)); 
int32_t m = projectint32(e, nthVL(args, 1)); 


switch (tag) { 

case PLUS: return mkNum(n + m); 
case MINUS: return mkNum(n - m); 
case TIMES: return mkNum(n * m); 


case DIV: if (m==0) runerror("division by zero"); 
else return mkNum(divide(n, m)); // round to minus infinity 
case LT: return mkBoolv(n < m); 
case GT: return mkBoolv(n > m); 
default: assert(0); 
3 


Other binary primitives 


pScheme has two other binary primitives, which don't require integer arguments: 
cons and =. The implementation of = is relegated to the Supplement, but the im- 
plementation of cons is shown here. Because S-expressions are a recursive type, 
a cons cell must contain pointers to S-expressions, not S-expressions themselves. 
Every cons must therefore allocate fresh locations for the pointers. This behavior 
makes cons a major source of allocation in uScheme programs."* 

161c. (prim.c 161a) += <161b 162aD 


Value cons(Value v, Value w) { 
return mkPair(allocate(v), allocate(w)); 


3 


MTn full Scheme, a cons cell is typically represented by a pointer to an object allocated on the heap, 
so cons requires only one allocation, not two. 
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allocate 
bindalloc 
checkargc 
echo 

env 

eval 
evaldef 
type Exp 
find 
lengthVL 
mkBoolv 
mkLambdax 
mkNum 
mkPair 
mkVal 
nthVL 
runerror 
strtoname 
unspecified 
type Value 


Sie aye 
eB gee 8 


aN 
Ni 
eX) 


43b 
154d 
A 


type Valuelist 


$309c 


Unary primitives 


Unary primitives are implemented here. Most of the cases are relegated to the Sup- 
plement. 
162a. (prim.c 161a) += <161c 
Value unary(Exp e, int tag, Valuelist args) { 
checkargc(e, 1, lengthVL(args)); 


Scheme, Value v = nthVL(args, 0); 
S-expressions, and switch (tag) £ 
first-class functions case NULLP: 
return mkBoolv(v.alt == NIL); 
162 case CAR: 


if (v.alt == NIL) 
runerror("in %e, car applied to empty list", e); 
else if (v.alt != PAIR) 
runerror("car applied to non-pair %v in %e", v, e); 
return *v.pair.car; 
case PRINTU: 
if (v.alt != NUM) 
runerror("printu applied to non-number %v in %e", v, e); 
print_utf8(v.num); 
return v; 
case ERROR: 
runerror("%v", v); 
return v; 
(other cases for unary primitives $314c) 
default: 
assert(0); 


2.12.6 Memory allocation 


In this chapter, a new location is allocated with malloc. 
162b. (loc.c 162b)= 
Value* allocate(Value v) £¢ 
Value *loc = malloc(sizeof(*loc)); 
assert(loc != NULL); 
*loc =v; 
return loc; 


3 
A much more interesting and efficient allocator is described in Chapter 4. 


2.13 EXTENDING WSCHEME WITH SYNTACTIC SUGAR 


Like Impcore, psScheme is stratified into two layers: a core language and syntactic 
sugar (page 68). The core language is defined by the operational semantics and 
is implemented by functions eval and evaldef. The syntactic sugar is defined and 
implemented by translating it into the core language. In Scheme, the core language 
can be very small indeed: even the LET and BEGIN forms can be implemented as 
syntactic sugar. (But in Scheme, they are part of the core.) The translations of 
LET and BEGIN are shown below, as are the translations used to implement short- 
circuit conditionals, cond, and the record form. These translations introduce two 
key programming-language concepts: capture-avoiding substitution and hygiene. 


2.13.1 Syntactic sugar for LET forms 


A let expression can be desugared into an application of a lambda: 


(let ([41 €1] +++ [an @n]) €) = ((ambda (a1 +++ &_) e) €1 +++ En). 


A let* expression can be desugared into a sequence of nested let expressions. 
The desugaring is defined by structural induction on the list of bindings in the let*, 
which calls for two equations: one for the base case (no bindings) and one for the 
induction step (a nonempty sequence of bindings). An empty let* is desugared 
into its body. A nonempty let* is desugared into a nested sequence of let expres- 
sions: a let expression for the first binding, followed by the desugaring of the let* 
expression for the remaining bindings. 


(let* () e) 
(let* ([%1 €1] +++ [%n €n]) €) 
(let ([21 €1]) (let* ([%2 €2] +++ [%n €n]) €)) 


[> |e 


This translation works just like any other recursive function—but the recursive 
function is applied to syntax, not to values. It looks like this: 
163. (parse.c 163)= 
Exp desugarLetStar(Namelist xs, Explist es, Exp body) £ 
if (xs == NULL || es == NULL) £ 
assert(xs == NULL && es == NULL); 
return body; 
3 else § 
return desugarLet(mkNL(xs->hd, NULL), mkEL(es->hd, NULL), 
desugarLetStar(xs->tl, es->tl, body)); 


3 
The desugared code works just as well as pScheme’s core code—and you can prove it 
(Exercises 44 and 45). 
Finally, a letrec can be desugared into a let expression that introduces all the 
variables, which is followed by a sequence of assignments: 


(letrec ([#1 €1] -++ [an €n]) €) = 
(let ([x%1 unspecified] --- [%, unspecified]) 
(begin (set x1 €1)--- (set Ln Cn) 
e)). 


This translation works only when each e; is a lambda expression, as required by the 
operational semantics. 


2.13.2 Syntactic sugar for cond (Lisp’s original conditional form) 


pScheme’s conditional expression, written using if, allows for only two alterna- 
tives. But real programs often choose among three or more alternatives. For some 
such choices, C and the Algol-like languages offer a switch statement, but it can 
choose only among integer values that are known at compile time—typically enu- 
meration literals. A more flexible multi-way choice is offered by a syntactic form 
from McCarthy’s original Lisp: the cond expression. A cond expression contains an 
arbitrarily long sequence of question-answer pairs: one for each choice. I like cond 
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checkarge 47c 
type Exp A 
type Explist S309b 
lengthVL A 


mkBoolv A 
mkEL A 
mkNL A 
type Namelist 

43a 
nthVL A 
print_utf8 S188a 
runerror 47a 
type Value <A 
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more than if because cond makes it obvious how many alternatives there are and 
what each one is doing. 


164a. (transcript for extended juScheme 164a) = 164b > 
-> (define compare-numbers (n m) 
(cond 
[(< n m) ‘less] 
[(= n m) "equal] 


Scheme, [(> n m) "greater])) 
S-expressions, and -> (compare-numbers 3 2) 
first-class functions greater 

-> (compare-numbers 3 3) 
164 equal 

-> (compare-numbers 3 4) 

less 


As another example, cond can be used to implement remove-multiples, from 
chunk 102b: 
164b. (transcript for extended j1Scheme 164a) += <1164a 167a> 
-> (define divides? (p n) (= (mod n p) 0)) 
-> (define remove-multiples (p ns) 


(cond [(null? ns) 'O] 
[(divides? p (car ns)) (remove-multiples p (cdr ns))] 
[#t (cons (car ns) 


(remove-multiples p (cdr ns)))])) 
-> (remove-multiples 3 '(1 23 45 6)) 
(1 2 4 5) 


Although cond is superior, it is found in very few languages—almost exclusively 
the Lisp-like languages—and if is found everywhere. For uScheme, therefore, 
I chose the familiar if over the superior cond. Fortunately, now that you know 
about cond, you can use it—it’s syntactic sugar: 


(cond) 
(cond [€g €a] --- 


(error 'cond:-all-question-results-were-false) 


He [le 


(if €g €a (Cond---)) 


2.13.3 Syntactic sugar for conditionals: Avoiding variable capture 


As a replacement for the primitive function and, which can be called only after 
both its arguments are evaluated, jsScheme provides a syntactic form && which 
evaluates its second argument only when necessary. And actually, && can accept 
more than two arguments; it is desugared to if expressions as follows: 


e 
(if e€1 (&& ey «++ Cp) #f) 


(&& €) 
(&& €7 +++ En) 


le [> 


pScheme also provides a | | form, which is also desugared into if expressions, but 
there’s a challenge. The following desugaring doesn’t always work: 


(| | €1 €2) A Cif e1 #t e2) 


The problem with that right-hand side is that if e isnot #f, (| | €1 €2) should return 
the value of e1, just as the predefined function or does. But the desugaring into if 


returns #t: 

164c. (transcript 95a) += 143d 165aD 
-> (or 7 'seven) 
7 


-> (if 7 #t 'seven) 
#t 


When €; is not #f, a desugaring could return €, but this desugaring doesn’t always 
work either: 


(| | €1 €2) A Cif e1 €1 €2) 


This one fails because it could evaluate e, twice. And if e; has a side effect, the 
desugaring performs the side effect twice, leading to wrong answers. 
165a. (transcript 95a) += <1164c 165b> 
-> (val n 2) 
-> (or (< 0 (set n (- n 1))) 'finished) 
#t 
-> (val n 2) 
-> (if (< 0 (set n (- n1))) (< @ (set n (- n1))) 'finished) 


The or function works because it is a function call: both e; and e€2 are evaluated, 
and their results are bound to the formal parameters of the or function. A desug- 
aring could achieve the almost same effect with a let binding: 


(| | e1 €2) is almost (let ([x €1]) (if x x e2)). 


This one works with the examples given so far: 

165b. (transcript 95a) += <1165a 165¢> 
-> (val n 2) 
-> (or (< 0 (set n (- n 1))) 'finished) 


-> (val n 2) 
-> (let ([x (< 0 (set n (- n 1)))]) (if x x 'finished)) 


But binding x doesn’t always work; if x is used in €2, the desugaring can fail: 
165¢. (transcript 95a) += <165b 185b> 
-> (val n 0) 
-> (val x 'finished) 
-> (or (< On) x) 
finished 
-> (val n 0) 
-> (val x 'finished) 
-> (let ([x (< 0 n)]) (Cif x x x)) 
#f 


This failure has a name: the global variable x is said to be captured by the desugar- 
ing. To avoid capturing x, it is sufficient to choose some name zx that doesn’t appear 
in €g. Such an 2 is called fresh. So finally, the following desugaring always works: 


(|| e; €9) = (let ([we1]) (if xe €2)), provided x does not appear in €2. 
Using this idea, the general rules for desugaring | | are as follows: 


e€ 


(let ([@ e1]) (if z@ (|| €2 +--+ €n))); 
where x does not appear in any e;. 


CII e) 
Cll e€1 +++ en) 


> |]> 


Variable capture and fresh names are perennial issues in programming languages. 


2.13.4 Hygienic substitution: Making syntactic sugar precise 


Desugaring replaces one expression with another. To define replacement precisely, 
programming-language theorists have developed the concept of substitution. 
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* Substitution is the computational engine driving the simplest, most founda- 
tional accounts of what it means to evaluate expressions (or run programs). 
If you ever study the lambda calculus, you'll see that substitution is its only 
computational mechanism. 


Substitution is used to check the types of polymorphic functions. wScheme’s 
functions aren't typechecked, and C’s functions aren't polymorphic, but 
many programming languages do support both polymorphism and type 
checking (Chapter 6). And when a polymorphic function is used, the cor- 
rectness of the use is checked using substitution. Such substitutions must 
avoid capturing type variables (Section 6.6.7). Even when types are inferred, 
as in ML and Haskell they are inferred using substitution (Chapter 7). 


In Prolog, when the system is trying to answer a query or prove a goal, sub- 
goals are spawned using substitution. 


Substitution algorithms that avoid variable capture are called hygienic. They are 
hard to get right. But if you are interested in programming-language foundations, 


you 


need to understand them. And if you are interested in language design, you 


need to understand that using a language based on substitution is not fun. (As ex- 
amples, I submit TeX and Tcl.) The more different contexts in which you see sub- 
stitution, the better you will understand it. 

Let’s use substitution to take a second look at zScheme’s conditional expres- 


sion 


1. 


The 


s. The expression (&& €; €2) is desugared into an if expression in three steps: 


The replacement will be derived from the template expression (if 01 2 #f). 
Mathematically, the symbols G, and D2 are ordinary program variables; the 
notation telegraphs an intention to substitute for them. 


Subexpressions e, and €2 are extracted from the && expression. 


In the template, e; is substituted for O; and €2 is substituted for H2, simulta- 
neously. The resulting expression is an instance of the template—“instance” 
being the word for a thing obtained by substitution. The original && expres- 
sion is replaced by the instance of the template, which is (if e; €2 #f). 


original expression and its replacement have the same semantics: 


* If the original && expression is evaluated in environment p, both e; and e2 
are supposed to be evaluated in environment p. In addition, expression €2 is 
supposed to be evaluated only if e; evaluates to #f. 


- If the instantiated template (the if expression) is evaluated in environ- 
ment p, the semantics confirms that both e; and e2 are evaluated in envi- 
ronment p. In addition, expression €2 is evaluated only if e; evaluates to #f. 


The | | expression can't be desugared so easily. 


* If the original || expression is evaluated in environment p, both e; and e2 
are supposed to be evaluated in environment p. 


* Ifthe template for | | is 


(let ([xO1]) (if x xO2)) 


and the instance is evaluated in environment p, then e, is evaluated in envi- 
ronment /, but if e2 is evaluated, it is evaluated in environment p{x +> v;}, 
where v} is the value of e1. 


Using this template, e2 is evaluated in an extended environment, and variable x can 
be captured. For example, if (e1, 0,0) |) (BOOLV(#f), 0’) and if eg is x, the value 
of the | | expression should be o’(p(x)). But the value of the instantiated template 
is always BOOLV(#f). If, however, x is not mentioned in eg, then x is not captured 
by the substitution, and it is a theorem that 


If (e, p,o) J) (vu, 0), if x is not mentioned in e, and if 2 ¢ domo, then §2.13 
(e, p{x > bb afl vu’) | (u,o). Extending 
pScheme with 
This theorem follows either from Exercise 52 in this chapter or from Exercise 9 in syntactic sugar 
Chapter 5. 7s 


Therefore, | | can be desugared correctly if we choose a good x. Instead of a 
single template for | |, think of a whole family of templates 


{(let ([vo1]) (if vv O2)) | xisa variable}. 


Every choice of x determines a template, and any given e, and e€2 can be desugared 
using any template in which x does not appear in €2. 


2.13.5 Syntactic sugar for BEGIN 


The same idea of hygiene—choosing a variable in a template that does not interfere 
with what is substituted—is used in the rules for desugaring BEGIN: 


e 


(let ([@ €1]) (begin ez --- €n)), 
where x does not appear in any e;. 


(begin e) 
(begin e, -:- €n) 


& 
A 


2.13.6 Syntactic sugar for records 


A Scheme record contains a fixed collection of named fields. In modern implemen- 
tations of full Scheme, records are provided natively, as a primitive data structure. 
In uScheme, records are simulated using cons cells. The record-definition form in 
Section 2.4.1 is desugared into a sequence of function definitions: 
167a. (transcript for extended Scheme 164a) += <164b 167b> 

-> (record frozen-dinner [protein starch vegetable dessert]) 

make-frozen-dinner 

frozen-dinner? 

frozen-dinner-protein 

frozen-dinner-starch 

frozen-dinner-vegetable 

frozen-dinner-dessert 


A frozen-dinner is represented by a list with five elements: the symbol 
make-frozen-dinner, followed by the values of the fields. This representation, 
when printed, resembles code that might be executed to reconstruct the record. 
167b. (transcript for extended j1Scheme 164a) += <1167a 


-> (make-frozen-dinner 'steak 'potato 'green-beans 'pie) 
(make-frozen-dinner steak potato green-beans pie) 


Using this representation, the record definition is desugared into a sequence 
of definitions, the first of which looks something like this: 
167c. (selected equivalent definitions for record frozen-dinner 167c)= 168 > 
(define make-frozen-dinner (x y z w) 
(cons 'make-frozen-dinner (cons x (cons y (cons z (cons w '())))))) 


(The remaining definitions follow.) 
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And the remaining definitions: 
168. (selected equivalent definitions for record f rozen-dinner 167c) += <1167¢ 
(define frozen-dinner? (v) 
(&& (pair? v) 
= 'make-frozen-dinner (car v)) 
(pair? (cdr v)) 
(pair? (cddr v)) 
(pair? (cdddr v)) 
(pair? (cdr (cedddr v))) 
(null? (cddr (cdddr v))))) 
(define frozen-dinner-protein (r) 
(if (frozen-dinner? r) 
(car (cdr r)) 
(error (list2 r 'is-not-a-frozen-dinner-record)))) 
(define frozen-dinner-starch (r) 
(if (frozen-dinner? r) 
(car (cdr (cdr r))) 
(error (list2 r 'is-not-a-frozen-dinner-record)))) 
In general, a record definition with record name r and field names f;,..., fn 
is desugared as follows:!° 
(recordr (fi --- fn)) = 
(define make-r (21 +--+ In) 
(cons 'make-r (cons x1 (cons::- (cons % '()))))) 
(define 7? (x) (&& (pair? x) (= (car x) 'make-7) ---)) 
(define r-fi (x) (if (r? x) (car (cdr x)) (error:--))) 
(define r-fo (x) (if (r? x) (car (cdr (cdr x))) (error---))) 


(define r-fn (x) (if (7? x) 
(car (cdr (cdr-:-- (cdr x)))) 
(error::-))) 
In make-r, hygiene requires that ©), ... , Z», be mutually distinct and different from 
cons; otherwise cons could mistakenly refer to one of the arguments. Hygiene is 
discussed more deeply in Section 2.14.4. 


2.14 SCHEME AS IT REALLY IS 


Like Lisp before it, Scheme has split into dialects. The model for puScheme is the 
1998 RRS standard, which embodies the minimalist design philosophy of the orig- 
inal Scheme. The 2007 RRS standard defines a bigger, more complicated Scheme, 
which most R°RS implementations chose not to adopt. The subsequent R’RS stan- 
dard splits Scheme into two languages: a small one, finalized in 2013, that more 
closely resembles the original, and a big one, still incomplete as of 2022, that is 
believed to be better suited to mainstream software development. And while stan- 
dards have their advantages, many Schemers prefer Racket, a nonstandard dialect 
that benefits from a talented team of developers and contributors. But most di- 
alects share aspects that I consider interesting, impressive, or relevant for some- 
one making a transition from puScheme—which is the topic of this section. 


2.14.1 Language differences 


Let’s begin with some minor lexical and syntactic differences. Through 2007, iden- 
tifiers and symbols in full Scheme were not case-sensitive; for example, 'Foo was 


The real story is more complicated: instead of using names cons, pair?, car, and so on, the desug- 
aring creates literals that refer directly to those primitives. 


the same as 'foo. But as of the 2007 R°RS standard—to give it its full name, the 
Revised® Report on Scheme (Sperber et al. 2009)—identifiers and symbols are case- 
sensitive, as in zScheme. 

Full Scheme uses define to introduce all top-level bindings, with slightly dif- 
ferent concrete syntax from puScheme: 


(define var exp) 
(define (fun args) exp) 


The define form can also be used within the body of a let or a lambda. Using 
definition forms within let and lambda makes programs easier to read and refactor 
than in jzScheme, and it’s cheap: these forms are desugared to a new letrec* form, 
which uses a single environment like letrec but is evaluated sequentially like let*. 
Full Scheme operates on association lists with a function called assoc, not with 
find and bind. (In full Scheme, find is a function that takes a predicate and a 
list and returns the first element of the list that satisfies the predicate.) Calling 
(assoc obj alist) finds the first pair in alist whose car field is equal? to obj, 
and it returns that pair. If no pair in alist has obj as its car, assoc returns #f. 


169a. (R°RS Scheme transcript 169a)= 169b> 
> (define e '((a 1) (b 2) (c 3))) 7; r6rs Scheme implemented in Racket, 
> (assoc 'a e) 77 not pScheme! 
"(a 1) 
> (assoc 'b e) 
"(b 2) 
> (assoc 'd e) 
tf 
> (assoc (list 'a) '(((a)) ((b)) ((c)))) 
"((a)) 


A result from assoc can be tested directly in an if expression, and if not #f, it can 
be updated in place by primitive function set-cdr!. 

Full Scheme includes the other list functions found in jsScheme, but often un- 
der slightly different names, such as for-all, exists, fold-left, and fold-right. 
And the full Scheme functions are more general: they can operate on any number 
of lists simultaneously. 

Full Scheme has an additional quoting mechanism: using quasiquotation, you 
can splice computed values or lists into quoted S-expressions (Exercise 55). 

In full Scheme, a function can take a variable number of arguments. Either 
the function takes one formal parameter, which is the whole list of arguments, ora 
formal parameter separated by a trailing period is bound to any “extra” arguments: 
169b. (RORS Scheme transcript 169a) += 1169a 

> ((lambda (x y . zs) zs) 3 45 6) 7; Racket's r6rs Scheme 

"(5 6) 

> ((lambda xs xs) 3.45 6) 

'(3 4 5 6) 
In addition, many primitive functions and macros, such as +, <, and, max, etc., ac- 
cept an arbitrary number of arguments—even zero. 

In full Scheme, the syntactic form set is called set!. And full Scheme can 
mutate the contents of cons cells, not just variables, using primitive functions 
set-car! and set-cdr! (Exercises 50 and 58). 

Finally, in full Scheme, the order in which expressions are evaluated is usually 
unspecified. To enforce a particular order of evaluation, use let* or letrec*. 
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2.14.2 Proper tail calls (upcoming in Chapter 3) 


Implementations of full Scheme must be properly tail-recursive. Informally, an im- 
plementation is properly tail-recursive if every tail callis optimized to act as a “goto 
with arguments,” that is, it does not push anything on the call stack (Steele 1977). 
An arbitrarily long sequence of tail calls takes no more space than one ordinary 
call. 

Intuitively, a call is a tail call if it is the last thing a function does, i.e., the result 
of the tail call is also the result of the calling function. As an important special 
case, proper tail recursion requires that if the last thing a full Scheme function does 
is make a recursive call to itself, the implementation makes that recursive call as 
efficient as a goto. 

Many tail calls are easy to identify; for example, in a C program, the last call 
before a return or before the end of a function is a tail call. And in a C statement 
return f (args), the call to f isa tail call. To identify all tail calls, however, we need 
a more precise definition. 

In Scheme, a tail call is a function call that occurs in a tail context. Tail contexts 
are defined by induction over abstract syntax. The full story is told by in Kelsey, 
Clinger, and Rees (1998, Section 3.5), from whom I have adapted this account, but 
the key rules look like this: 


* The body of a lambda occurs in a tail context. 
* When (if e; eg e3) occurs ina tail context, e2 and es occur ina tail context. 


* When (begin e; eg ... €,) occurs in a tail context, e,, occurs in a tail con- 
text. 


* Whena let, let*, or letrec occurs in a tail context, the body of the let occurs 
in a tail context. 


The following example shows one tail call, to f. The calls to g and h are not tail 
calls. The reference to x is in a tail context, but it is not a call and so is not a tail 
call. 


(lambda () 
(if (g) 
(let ([x (h)]) 
x) 
(if (g) (f) #f))) 


The definition of tail context gives us a precise way to identify a function in 
continuation-passing style (Section 2.10.1): a function is written in continuation- 
passing style if and only if every expression in a tail context is either a call to a 
parameter or is a call to a function that is written in continuation-passing style. 

The interpreter in this chapter does not optimize tail calls. But the interpreter 
in Chapter 3 does, and Chapter 3’s exercises can help you understand how proper 
tail calls work and how they affect the use of stack space. 


2.14.3 Data types 


Full Scheme has more primitive data types and functions than puScheme. These 
types include mutable vectors (arrays), which can be written literally using the 
#(...) notation, as well as characters, mutable strings, and “I/O ports.” And the 
RRS and R’RS standards include records with named fields; sScheme’s record 
form (Section 2.13.6) is a scaled-down version of R®RS records. 

Full Scheme supports lazy computations with delay and force. 


Full Scheme provides many types of numbers, the meanings and representa- 
tions of which are carefully specified in the standard. Numeric types can be ar- 
ranged in a tower, in which each level contains all the levels below it: 


number 

complex 

real 

rational 

integer 
Numbers may also be exact or inexact. Most Scheme implementations, for exam- 
ple, automatically do exact arithmetic on arbitrarily large integers (“bignums’”). 
If you are curious about bignums, you can implement them yourself; do Exer- 
cises 49 and 50 in Chapter 9 or Exercises 37 to 39 in Chapter 10. 


2.14.4 From syntactic sugar to syntactic abstraction: Macros 


Full Scheme includes not only the syntactic sugar described in Section 2.13 but also 
the ability for programmers to define new forms of syntactic sugar, called macros 
(or syntactic abstractions). Macros have the same status as any other Scheme code: 
they can be included in user code and in libraries, and anybody can define one by 
writing a macro transformer. And Scheme’s macros are hygienic: 


* If a macro transformer inserts a binding for an identifier (variable or key- 
word) not appearing in the macro use, the identifier is in effect renamed 
throughout its scope to avoid conflicts with other identifiers. For example, 
just as prescribed by the rules in Section 2.13.3, if a macro transformer ex- 
pands (|| e€1 €2) into (let ([t e,]) (if tt e2)), then t is automatically re- 
named to avoid conflicting with identifiers in e,; and eg. Standard Scheme 
does something similar with or; the expression (or e€; €2) is defined to ex- 
pand to (let ([x e1]) (if x x e€2)). Scheme’s macro facility renames x as 
needed to avoid capture. 


Hygiene also protects each macro’s unbound names. For example, jsScheme’s 
record definition desugars into definitions that use cons, car, cdr, and pair? 
(Section 2.13.6). These names must not take their meanings from the context 
in which the record definition appears, as shown by this contrived example, 
which mixes ;sScheme with full Scheme: 


(let ([z 5]) 
(define (cons y ys) 'you-lose) 
(define (pair? x) #f) 
(record point (x y)) 
(assert (point? (make-point 3 4)))) 


If record were desugared naively, the code for point? would use the ver- 
sion of pair? that’s in scope, and the assertion would fail. But the asser- 
tion (point? (make-point e; €2)) should always succeed. And in a truly 
hygienic macro system, it does: the hygienic macro system guarantees that 
when a macro is desugared, its free names refer to the bindings visible where 
the macro was defined, regardless of how those names may be bound where 
the macro is used. 


Hygiene makes Scheme macros remarkably powerful. Macro transformers can de- 
fine new language features that in most settings that would require new abstract 
syntax. A good implementation of Scheme is more than just a programming lan- 
guage; it is a system for crafting programming languages. Details, examples, and 
ideas can be found in some of the readings mentioned in Section 2.15.2. 
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2.14.5 call/cc (also upcoming in Chapter 3) 


Full Scheme includes a primitive function which can capture continuations that 
are defined implicitly within the interpreter, as if a program had been written 
in continuation-passing style. Primitive call-with-current-continuation, also 
called call/cc, can help you implement a staggering variety of control structures, 
including backtracking, multiple threads, exceptions, and more. Such control oper- 
ators are a major topic of Chapter 3. 


2.15 SUMMARY 


Functional programming is a style of programming that relies on first-class, nested 
functions—in other words, on lambda. Functional programmers compose func- 
tions aggressively; they use functions to make other functions. Typical patterns 
of composition and computation are embodied in standard higher-order functions 
like maps, filters, and folds, where they can easily be reused. Such compositions 
emphasize “wholemeal programming”: code is composed of operations on whole 
lists or whole S-expressions, not of operations on one element at a time. Func- 
tional programming also emphasizes the use of immutable data: rather than mu- 
tate a variable, the experienced functional programmer usually binds a new one, 
as discussed on page 119. Immutability simplifies unit testing and enables more 
function composition. And thanks to very fast allocators (Chapter 4), immutability 
can be implemented efficiently. 


2.15.1 Key words and phrases 


ATOM A Scheme value that can be compared for equality in constant time: a sym- 
bol, a number, a Boolean, or the empty list. Atoms are the base case in the 
definition of S-EXPRESSIONS. 


CLOSURE The run-time representation of a function, produced by evaluating a 
LAMBDA ABSTRACTION. Includes a representation of the function's code and 
references to its FREE VARIABLES—or their locations. Closures are the sim- 
plest way to implement FIRST-CLASS, NESTED functions. A closure can be op- 
timized to refer only to those free variables that are not also global variables— 
that is, the LET-bound and LAMBDa-bound variables of enclosing functions. 


CONS, CAR, CDR The basic primitives that operate on lists, or more generally, 
S-EXPRESSIONS. By rights, nul1? should have equal status with cons, car, 
and cdr, but for some reason it is rarely mentioned in the same breath. 


FILTER A HIGHER-ORDER FUNCTION that selects just some elements from a con- 
tainer structure—usually a list—according to a predicate function that is 
passed in. 


FIRST-CLASS FUNCTION A function value that enjoys the same privileges as simple 
scalar values like machine integers: it may be passed to other functions, re- 
turned from other functions, stored in local and global variables, and stored 
in objects allocated on the heap, such as CONS CELLS. Most useful when 
NESTED. Functions in Scheme, Icon, and C are first-class values, but func- 
tions in Impcore are not. 


FIRST-ORDER FUNCTION A function whose arguments and results are not func- 
tions and do not contain functions. Compare with HIGHER-ORDER FUNC- 
TION. 


FOLD A HIGHER-ORDER form of “reduction” that uses a given function to combine 
all elements of a container structure—usually a list. Folds can be used to im- 
plement sum, product, map, filter, and a zillion other functions that combine 
information two elements at a time. Like MAPS, folds can be found on lists, 
strings, mutable and immutable arrays, sets, trees, and so on. 


FREE VARIABLE A name appearing in the body of a function that is bound neither 
by the LAMBDA ABSTRACTION that introduces the function nor by any LET 
BINDING within the body of the function. Names that refer to primitives like 
+ and cons are typically free variables. LOCATIONS of free variables are cap- 
tured in CLOSURES. 


HIGHER-ORDER FUNCTION A function that either takes one or more functions as 
arguments, or more interestingly, that returns one or more functions as re- 
sults. Classic examples include MAP, FILTER, and FOLD. More interesting 
higher-order functions can be defined only in a language in which functions 
are both FIRST-CLASS and NESTED. Compare with FIRST-ORDER FUNCTION. 


LAMBDA ABSTRACTION The syntactic form by which a function is introduced. 
Scheme functions need not be named. 


LOCATION A reference to MUTABLE storage. In both the semantics and implemen- 
tation of Scheme, a variable stands for a MUTABLE location, not for a value, 
and what is captured in a CLOSURE are the locations of the FREE VARIABLES. 


LOCATION SEMANTICS A semantics in which a variable stands for a mutable Lo- 
CATION in a store, not for a value. Describes languages like C and Scheme. 
Contrast with VALUE SEMANTICS. 


Map Any of a family of HIGHER-ORDER FUNCTIONS that operate on a container— 
like a list—and apply a function to each value contained. Scheme provides 
maps only on lists, but functional languages that provide more data struc- 
tures provide more maps. For example, ML compilers typically ship with 
maps on lists, strings, mutable and immutable arrays, optional values, sets, 
and trees. 


MONOMORPHIC A property of a function or value that may be used only with val- 
ues of a single type. The word is Greek for “one shape.” As an example, the + 
primitive is monomorphic because it works only with integers. By contrast, 
the car primitive, because it works with lists whose elements are of any type, 
is POLYMORPHIC. 


MUTABLE Said of an entity whose state can change during the execution of a pro- 
gram, like a wScheme variable. The very word “variable” suggests that the 
value can vary, which is to say it is mutable. Mutability is ultimately imple- 
mented by reference to a machine LOCATION. In Scheme, variables are 
mutable but values are immutable. In full Scheme, records and CONS cells 
are mutable, using functions like set-car! and set-cdr!. 


NESTED FUNCTION A function defined within another function. Using STATIC 
SCOPING, a nested function has access to the formal parameters and local 
variables of the enclosing function. Most useful when FIRST CLASS (and im- 
plemented by CLOSURES). Functions in Scheme and Lua may nest and are 
first-class; functions in Pascal and Ada may nest but are not first-class. 


POLYMORPHIC A property of a function or value that may be used with more than 
one set of values. The word is Greek for “many shapes.” As an example, the 
length function is polymorphic because it works with any list, regardless 
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of what sorts of values are stored in the list. By contrast, the sum function 
(Exercise 29), because it works only on lists of integers, is MONOMORPHIC. 


S-EXPRESSION The basic datatype of Scheme. Also, the concrete, parenthesized- 
prefix syntax used to write Scheme. A fully general S-expression is either 
an ATOM or a CONS cell containing two S-expressions. An “ordinary” S- 
expression is either an atom or a list of ordinary S-expressions. 


SHARED MUTABLE STATE A means of communication ata distance, not evidentina 
function’s arguments and results. In Scheme, any variable is mutable and any 
variable can be captured in a CLOSURE, so any variable can contain shared 
mutable state. In C, only global variables can contain shared mutable state— 
and they can be shared by any two functions, which is why your instructors 
may have warned you against them. Mutable state can be protected from 
over-sharing by hiding it under a LAMBDA ABSTRACTION, as in the example of 
the resettable counter or the random-number seed (Section 2.7.1, page 124). 
When a function relies on mutable state, its abilities to be unit tested or to be 
composed with other functions may be compromised. 


SHORT-CIRCUIT EVALUATION Describes a syntactic form that looks like an ordi- 
nary function call or operator, but that does not evaluate all of its operations. 
Short-circuit evaluation is common for conjunction and disjunction (Boolean 
“and” and “or”), which in C and wScheme are written && and | |. 


STORE In semantics, the set of meaningful LOCATIONS. Typically implemented 
by a combination of machine memory and machine registers. May include 
memory locations on the call stack as well as on the managed heap. 


SYNTACTIC SUGAR Concrete syntax that extends a language by being translated 
into existing syntax. Examples in zScheme include SHORT-CIRCUIT condi- 
tionals and record definitions, among other forms (Section 2.13). 


VALUE SEMANTICS A semantics in which a variable stands for a value, not a muta- 
ble LOCATION. Describes languages like Impcore, ML, and Haskell. Contrast 
with LOCATION SEMANTICS. 


2.15.2 Further reading 


For insight into how a language is born, John McCarthy’s original paper (1960) and 
book (1962) about Lisp are well worth reading. But some later treatments of Lisp 
are clearer and more complete; these include books by Touretzky (1984), Wilen- 
sky (1986), Winston and Horn (1984), Graham (1993), and Friedman and Felleisen 
(1996). For the serious Lisper, the Common Lisp manual (Steele 1984) is an invalu- 
able reference. 

For Scheme, the closest analog is the “Lambda: The Ultimate —” series by Steele 
and Sussman (Sussman and Steele 1975; Steele and Sussman 1976, 1978); I espe- 
cially recommend the 1978 article. For reference, Dybvig’s (1987) book is clear and 
well organized, and there are always the official standards (Kelsey, Clinger, and 
Rees 1998; Sperber et al. 2009; Shinn, Cowan, and Gleckler 2013). 

Recursion isn't just for functional programmers; it is also highly regarded in 
procedural languages, as taught by Rohl (1984), Roberts (1986), and Reingold and 
Reingold (1988). Proper tail recursion is precisely defined by Clinger (1998), who 
also explores some of the implications. 


To argue that functional programming matters, Hughes (1989) shows that it 
provides superior ways of putting together code: tools like map, filter, and 
foldr enable us to combine small, simple functions into big, powerful func- 
tions. By Hughes’s standard, Scheme is only half a functional language: al- 
though ywScheme provides higher-order functions, it does not provide lazy evalu- 
ation, a technique now strongly associated with Haskell. 

Algebraic laws are explored in depth by Bird and Wadler (1988), who include 
many more list laws than I present. Algebraic laws are also a great tool for specify- 
ing the behavior of abstract data types (Liskov and Guttag 1986). The algebraic ap- 
proach can also be used on procedural programs, albeit with some difficulty (Hoare 
et al. 1987). And algebraic laws support a systematic, effective, property-based ap- 
proach to software testing (Claessen and Hughes 2000). 

Full Scheme can express a shocking range of programming idioms, algorithms, 
data structures, and other computer-science ideas; the demonstration by Abelson 
and Sussman (1985) is likely to impress you. Beginners will get more out of Har- 
vey and Wright (1994), who aim at students with little programming experience. 
Another approach for beginners uses five subsets of Scheme, which are carefully 
crafted to help raw beginners evolve into successful Schemers (Felleisen et al. 2018). 

The idea of using statically scoped closures to implement first-class, nested 
functions did not originate with Scheme. The idea had been developed in a num- 
ber of earlier languages, mostly in Europe. Examples include Iswim (Landin 1966), 
Pop-2 (Burstall, Collins, and Popplestone 1971), and Hope (Burstall, MacQueen, 
and Sannella 1980). The book by Henderson (1980) is from this school. Also highly 
recommended is the short, but very interesting, book by Burge (1975). 

Continuation-passing style was used by Reynolds (1972) to make the meanings 
of “definitional” interpreters independent of their implementation language. The 
continuation-passing backtracking search in Section 2.10 is based on a “Byrd box,” 
which was used to understand Prolog programs (Byrd 1980); my terminology is that 
of Proebsting (1997), who describes an implementation of Icon, which has back- 
tracking built in (Griswold and Griswold 1996). 

Macros are nicely demonstrated by Flatt (2012), who creates new languages 
using Scheme’s syntactic abstraction together with other tools unique to Racket. 
If you like the ideas and you want to define your own macros, continue with Hen- 
dershott’s (2020) tutorial. 

Macros have a long history. Kohlbecker et al. (1986) first addressed the problem 
of variable capture; they introduce a hygiene condition sufficient to avoid variable 
capture, and they define a hygienic macro expander. Dybvig, Hieb, and Brugge- 
man (1992) build on this work, reducing the cost of macro expansion and enabling 
macros to track source-code locations; a key element of their macro expander is 
the syntax object, which encapsulates not only a fragment of abstract-syntax tree 
but also some information about its environment, so that variable capture can be 
avoided. Moving from full Scheme to Racket, Flatt et al. (2012) further increase the 
power of the macro system by enabling macro expanders to share information. But 
the complexity of the system is acknowledged as a drawback; in particular, it is no 
longer so obvious that variable capture is always avoided. Flatt (2016) proposes a 
new, simpler model wherein a fragment of syntax is associated with a set of envi- 
ronments, which together determine the meaning of each name mentioned within 
the fragment. 
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2.16 EXERCISES 


The exercises are summarized in Table 2.8. Some of the highlights are as follows: 


+ Exercise 13 guides you to an efficient, purely functional representation of 
queues, without using mutation. 


Exercises 22 and 24 ask you to prove some classic algebraic laws of pure func- 
tional programming: append is associative, and the composition of maps is 
the map of the composition. The laws can be used to improve programs, 
sometimes even by optimizing compilers. The proofs combine equational 
reasoning with induction. 


Exercise 38 asks you to implement a “data structure” whose values are repre- 
sented as functions. 


Exercise 41 invites you to work toward mastery of continuation-passing style 
by implementing a solver for general Boolean formulas. 


Exercise 60 on page 198 asks you to add a trace facility to the wScheme inter- 
preter; it will help you master the C code for the evaluator. 


As you tackle the exercises, you can refer to Table 2.3 on page 97, which lists all 


the functions in jsScheme’s initial basis. 


2.16.1 Retrieval practice and other short questions 


rom oo 


What laws relate primitives car, cdr, nul1?, and cons? 
What laws describe the behavior of the map function? 


Given the definition (record sundae [ice-cream sauce topping]), what code 
do you write to find out if a sundae is topped with 'cherry? 


Given the same definition of sundae, how do you make an ice-cream sundae 
with vanilla ice cream, chocolate sauce, topped with sprinkles? 


Given a food value that might be a frozen-dinner or a sundae, how do you 
interrogate it to find out which one it is? 


To select all even numbers from a list of numbers, do you use map, filter, or 
a fold? 


To double all the numbers in a list of numbers, do you use map, filter, ora 
fold? 


To find the largest of a nonempty list of numbers, do you use map, filter, ora 
fold? 


What’s the cost of a naive list reversal? 
What’s the cost of a list reversal that uses accumulating parameters? 
According to function equal?, when are two S-expressions considered equal? 


According to primitive function =, when are two S-expressions considered 
equal? 


If you want to write procedural code in Scheme, are you better off using let 
or let*? 


Table 2.8: Synopsis of all the exercises, with most relevant sections 


Exercises Section Notes 


1to5 2.3.4 Functions that consume lists, including lists that repre- 


sent sets (§2.3.7). 


6and7 2.3.2 Functions that take accumulating parameters. 


8 and9 2.2,2.3.5 Lists all the way down—thatis, S-expressions. A little cod- 


ing and one proof (see §2.5.8). 


10 to 12 2.4 Functions involving records and trees. 

13 to 15 2.3, 2.5 Implement and specify purely functional data structures. 
I recommend using let to define local variables (§2.6). 

16 to 23 2.5 Equational reasoning with first-order functions. 

24 to 26 2.5 Equational reasoning with higher-order functions. 

27 to 30 2.8 Standard higher-order functions on lists. 

31 to 36 2.7, 2.8 Functions that take other functions as arguments. 

37 to 40 2.7 Functions that return new functions made with lambda. 

41 2.10 Continuations. 

42 to 45 2.11 Using the operational semantics to reason about alge- 


braic laws (§2.5) and syntactic sugar (§2.13). 


46 to 50 2.11 Using the operational semantics to explore alternatives 


to the existing design and the semantics of possible new 
features. 


5land52 2.11,1.7.3  Metatheory: absence of aliasing, safety of extended envi- 


ronments. 


53 to 55 2.12,2.13 Implementing syntactic sugar, and adding quasiquotation 


syntax for writing S-expressions. 


56 to 59 2.12.5 New primitives: list, apply, set-car!, set-cdr!, and 

read. 

60 2.12 Enhancement to the interpreter: tracing calls. 

N. What test is performed by the function (0 not ((curry =) 0))? 

O. Which of the following list functions are naturally polymorphic in the list ele- 
ment? length, sum, reverse, append, minimum, member?, sort 

P. Which of the following list functions are not naturally polymorphic but can be 
made so by passing an additional (function-valued) parameter? length, sum, 
reverse, append, minimum, member?, sort 

Q. Asearch function takes two continuations: one for success and one for failure. 
Which continuation expects a parameter? Why? 

R. In Impcore, a variable stands for a value v, but in zScheme, a variable stands 
for a location ?. What example in the chapter exploits this aspect of ~Scheme’s 
semantics? 

S. The equation (|| €1 €2) = (if e1 €1 €2) is not quite a valid algebraic law. 
What could go wrong? 

T. The equation (|| e1 e2) = (let ([x e1]) Cif x x €2)) is not quite a valid alge- 


braic law. What could go wrong? 
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2.16.2 Functions that consume lists 


1. Comparing elements of two lists. Implement both of the following functions: 


(a) 


(b) 


When both xs and ys are in set LIST(ATOM), contig-sublist? 
determines whether the first list is a contiguous subsequence of the 
second. That is, (contig-sublist? xs ys) returns #t if and only if 
there are two other lists front and back, such that ys is equal to 
(append (append front xs) back). 


(exercise transcripts 178a) = 
-> (contig-sublist? '(a bc) '(x a y b z c)) 


#f 
-> (contig-sublist? '(a y b) '(x a y b z c)) 
#t 
-> (contig-sublist? '(x) "(x ay bz c)) 
#t 


When both xs and ys are in set LIST(ATOM), sublist? determines 
whether the first list is a mathematical subsequence of the second. 
That is, (sublist? xs ys) returns #t if and only if the list ys contains 
the elements of xs, in the same order, but possibly with other values in 
between. 


(exercise transcripts 178a) += 
-> (sublist? '(a bc) '(x ay bzc)) 
#t 
-> (sublist? '(a y b) '(x ay bz c)) 
#t 
-> (sublist? '(a z b) '(x ay bzc)) 
#f 
-> (sublist? '(x y z) '(x ay bzc)) 
#t 


2. Numbers and lists of digits. Function explode-digits converts a nonnegative 
number to a list of its decimal digits, and function implode-digits converts 


back: 


(exercise transcripts 178a) += 
-> (explode-digits 1856) 


(1 8 5 6) 

-> (explode-digits 0) 

(®) 

-> (implode-digits '(2 4 6 8)) 
2468 


Implement explode-digits and implode-digits. 


Hint: A list of digits is much easier to work with if the least significant digit 
is first. Work with such lists, and at need, use reverse. 


3. Sets represented as lists. Implement the following set functions: 


(a) 


(b) 
(c) 


(remove x s) returns a set having the same elements as set s with ele- 
ment x removed. 


(subset? s1 s2) determines if s1 is a subset of s2. 


(=set? s1 s2) determines if lists s1 and s2 represent the same set. 


4. Sets as lists: Understanding equality. Chunks 105a and 105c use lists to rep- 
resent sets, and chunk 105d shows an example in which a set’s element may 
also be a list. In the text, I claim that if member? uses = instead of equal?, 
the example in chunk 105d doesn’t work. 


(a) In the example, which set functions go wrong? Is it add-element, 
member?, or both? 


(b) What goes wrong exactly, and why should the fault be attributed to us- $2.16 
ing the = primitive instead of the equal? function? Wipeaitns 
5. Synchronized access to two lists. Implement function dot-product, which 179 
computes the dot product of two vectors, represented as lists. (If the vec- 
tors are U1,...,Un and v1,..., Un, the dot product is uy - v1 +--+: +Un-: Un; 


where u,; - v; means multiplication.) 
(exercise transcripts 178a) += 
-> (dot-product '(1 2 3) '(10 5 2)) 
26 


2.16.3 Accumulating parameters 


6. Accumulating parameters and reversal. A list of things has an inductive struc- 
ture; it is either empty or is a cons cell containing a thing and a list of things. 
A numeral has a similar inductive structure; it is either a digit or is a numeral 
followed by a digit. If you've done Exercise 7 in Chapter 1, you've already im- 
plemented several functions that manipulate the digits of a decimal numeral. 
Here’s one to which you can apply the method of accumulating parameters de- 
scribed in Section 2.3.2: 


(a) Define a function reverse-digits, which is given a nonnegative num- 
ber and returns a number whose decimal representation is the decimal 
representation of the original number, but with the digits reversed. 
(exercise transcripts 178a) += 

-> (reverse-digits 123) 
321 

-> (reverse-digits 1066) 
6601 

-> (reverse-digits 100) 
1 

-> (reverse-digits 77) 
77 


Function reverse-digits could simply convert a number to a list of 
digits, call reverse, and convert the list back to a number. But look 
again at Section 2.3.2, and use similar ideas to define reverse-digits 
without ever materializing a list of digits.° By materializing only num- 
bers and Booleans, you will avoid allocating space on the heap. 


(b) Is the following algebraic law valid? 
(reverse-digits (reverse-digitsn)) =n 


Justify your answer. 


l6To materialize a value is to represent it explicitly during computation. In Scheme, a materialized 
value is stored in a location that is either referred to by name or is part of a cons cell. 
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7. Accumulating parameters and cost savings. Function preorder in Section 2.4.2 
may allocate unnecessary cons cells. Using the method of accumulating pa- 
rameters from Section 2.3.2, rewrite preorder so that the number of cons 
cells allocated is exactly equal to the number of cons cells in the final an- 


swer. 


2.16.4 From lists to S-expressions 


8. Inspection and manipulation of ordinary S-expressions. As described in Sec- 
tion 2.5.8, an ordinary S-expression is either an atom or a list of ordinary 
S-expressions—and of course a list of ordinary S-expressions is either empty 
or formed with cons. Using your understanding of these possible forms, im- 
plement functions count, countall, mirror, and flatten: 


(a) 


(b) 


(c) 


(d) 


When x is an atom and xs isin LIST(SEXPo), (count x xs) returns 
the number of (top-level) elements of xs that are equal to x. Assume x 
isnot '(). 
(exercise transcripts 178a) += 

-> (count 'a '(1 b a (c a))) 

1 


When x is an atom and xs is in LIST(SEXPo), (countall x xs) re- 
turns the number of times x occurs anywhere in xs, not only at top level. 
Assume x is not '(). 
(exercise transcripts 178a) += 

-> (countall 'a '(1 ba (c a))) 

2 


When xs is a list of S-expressions, (mirror xs) returns a list in which 
every list in xs is recursively mirrored, and the resulting lists are in 
reverse order. 
(exercise transcripts 178a) += 

-> (mirror '(1 2 3 4 5)) 

(5 4 3 2 1) 

-> (mirror '((a (b 5)) (ce d) e)) 

(e (dc) ((5 b) a)) 


Informally, mirror returns the S-expression you would get if you looked 
at its argument in a vertically oriented mirror, except that the individ- 
ual atoms are not reversed. (Try putting a mirror to the right of the ex- 
ample, facing left.) More precisely, mirror consumes an S-expression 
and returns the S-expression that you would get if you wrote the brack- 
ets and atoms of the original S-expression in reverse order, exchanging 
open brackets for close brackets and vice versa. 


Function flatten consumes a list of S-expressions and erases internal 
brackets. That is, when xs is a list of S-expressions, (flatten xs) con- 
structs a list having the same atoms as xs in the same order, but ina 
flat list. For purposes of this exercise, '() should be considered not as 
an atom but as an empty list of atoms. 
(exercise transcripts 178a) += 

-> (flatten '((I Ching) (U Thant) (E Coli))) 

(I Ching U Thant E Coli) 

-> (flatten '(((((a)))))) 

(a) 


(exercise transcripts 178a) += 
-> (flatten '()) 


O 
-> (flatten '((a) () ((b c) d e))) 
(a b cd e) 


9. Proof about S-expressions. Not only is a list of ordinary S-expressions itself 
an ordinary S-expression, a list of fully general S-expressions is also a fully 
general S-expression. Prove it. That is, using the inductive definitions of 
LIST (A) and SEXP pcg in Section 2.5.8, prove that 


LIST (SEXP pq) © SEXP rc. 


The theorem implies that if you are writing a recursive function that con- 
sumes a list of S-expressions, you could instead try to write a more gen- 
eral function that consumes any S-expression. The more general function 
is sometimes simpler. 


2.16.5 Records and trees 


10. Inspecting the contents of records. 


(a) Define a function desserts that takes a list of frozen dinners and re- 
turns a list of the desserts. 


(b) Using frozen-dinner?, define a function #dinners that takes a list of 
values and returns the number of values that are frozen dinners. 


(c) Define a function steak-dinners that takes a list of frozen dinners and 
returns a list containing only those frozen dinners that offer 'steak as 
a protein. 


11. Using node records to implement tree traversals. Using the representation de- 
fined in Section 2.4, define functions that implement postorder and inorder 
traversal for binary trees. 


12. Traversals of rose trees. A rose tree is a tree in which each node can have arbi- 
trarily many children. We can define an abstract rose tree as a member of 
the smallest set that satisfies this recursion equation: 


ROSE 4(A) = { (make-rosea ts) |ae AA ts € LIST(ROSE 4(A)) }. 


If we prefer to write rose trees as S-expression literals, we can define 
ROSE(A) = AU{ (consats) |ae AA ts € LIST(ROSE(A)) }. 


Extend the preorder and level-order traversals of Sections 2.4.2 and 2.6 to 
rose trees. Note that in the non-abstract ROSE representation, a leaf node 
labeled a can be represented in two ways: either as 'aor as '(a). 


2.16.6 Functional data structures 


13. Efficient queues. The implementation of queues in Section 2.6 (page 119) is 
simple but inefficient; enqueue can take time and space proportional to the 
number of elements in the queue. The problem is the representation: the 
queue operations have to get to both ends of the queue, and getting to the 
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14. 


15. 


back of a list requires linear time. A better representation uses two lists 
stored in a record: 


(record queue [front back]) 


In this record, 


* The queue-front list represents the front of the queue. It stores older 
elements, and they are ordered with the oldest element at the begin- 
ning, so functions front and without-front can be implemented us- 
ing car and cdr. 


* The queue-back list represents the back of the queue. It stores young 
elements, and they are ordered with the youngest element at the begin- 
ning, so function enqueue can be implemented using cons. 


The only trick here is that when the queue-front elements are exhausted, 
the queue-back elements must somehow be transferred to the front. Us- 
ing the two lists, implement value emptyqueue and functions empty?, front, 
without-front, and enqueue. Each operation should take constant time on 
average. (Proofs of average-case time over a sequence of operations use 
amortized analysis.) 


Algebraic laws for queues. The inefficient queue operations in Section 2.6 and 
the efficient queue operations in Exercise 13 can both be described by a sin- 
gle set of algebraic laws. As explained in Section 2.5.2, such laws must specify 
the result of applying any acceptable observer to any combination of con- 
structors. (The queues in this chapter are immutable, so mutators do not 
come into play.) 


+ Any queue can be constructed by applying enqueue zero or more times 
to emptyqueue. 


* Only three operations get information from (observe) queues: empty?, 
front, and without-front. 


Write algebraic laws sufficient to specify the behavior of all meaningful com- 
binations of constructors and observers. Don't try to specify erroneous com- 
binations like (front emptyqueue). 


Hint: This exercise is harder than it may appear—if you're not careful, you 
may find yourself specifying a stack, not a queue. Consider turning each 
algebraic law into a function, so you can test it as shown in Exercise 36. 


Graphs represented as S-expressions: Topological sort. Many directed graphs can 
be represented as ordinary S-expressions. For example, if each node is la- 
beled with a distinct symbol, a graph can be represented as a list of edges, 
where each edge is a list containing the labels of that edge’s source and des- 
tination. Write a function that topologically sorts a graph specified by this 
edge-list representation. The function (tsort edges) should return a list that 
contains the labels in edges, in topological order. 


In topological sorting, the two symbols in an edge introduce a precedence con- 
straint: for example, if '(ab) is an edge, then in the final sorted list of la- 
bels, a must precede b. As an example, (tsort '((ab) (ac) (cb) (db))) 
can return either '(adcb) or '(acdb). 


2.16.7 Equational reasoning with first-order functions 
16. 
17. 
18. 
19. 
20. 
21. 
22. 


23. 


Not every graph can be topologically sorted; if the graph has a cycle, function 
tsort should call error. 


For details on topological sorting, see Sedgewick (1988, Chapter 32), or Knuth 
(1973, Section 2.2.3). 
(exercise transcripts 178a) += 
-> (tsort '((duke commoner) (king duke) (queen duke) (country king))) 
(queen country king duke commoner) 
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Prove that (member? x emptyset) = #f. 


Prove that for any predicate p?, (exists? p? '()) = #f. 

Prove that for any list of values xs, (all? (lambda (_) #t) xs) = #t. 
Prove that (member? x (add-element x s)) = #t. 

Prove that (length (reverse xs)) = (length xs). 

Prove that (reverse (reverse xs)) = xs. 

Prove that (append (append xs ys) zs) = (append xs (append ys zs)). 


Prove that (flatten (mirror xs)) = (reverse (flatten xs) ), where func- 
tions flatten and mirror are defined as in Exercise 8. 


2.16.8 Equational reasoning with higher-order functions 


24. 


25. 


26. 


Prove that the composition of maps is the map of the composition: 
(map f (map g xs)) = (map (0 f g) xs) 


Prove again that the composition of maps is the map of the composition, but 
this time, prove equality of two functions, not just equality of two lists: 


(o ((curry map) f) ((curry map) g)) = ((curry map) (0 f g)) 


To prove that two functions are equal, show that when applied to equal argu- 
ments, they always return equal results. 


Prove that if takewhile and dropwhile are defined as in Exercise 31, then for 
any list xs, (append (takewhile p? xs) (dropwhile p? xs)) = xs. 


2.16.9 Standard higher-order functions on lists 


27. 


Select a subsequence of elements. Define function remove-multiples-too, 
which does what remove-multiples does, but works by using the higher- 
order functions in the initial basis. Copy function divides? from chunk 102a, 
and use whatever you like from the initial basis, but do not otherwise use 
lambda, if, or recursion. 
(exercise transcripts 178a) += 


-> (remove-multiples-too 2 '(2 3 45 6 7)) 
(3 5 7) 


28. Maps and folds with scalar results. Use map, curry, fold1, and foldr to define 
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29. 


30. 


the following functions: 


(a) cdr*, which lists the cdr’s of each element of a list of lists: 
(exercise transcripts 178a) += 
-> (cdr* '((a bc) (d e) (f))) 
((b c) (e) ()) 
(b) max*, which finds the maximum of a nonempty list of integers 


(c) gcd*, which finds the greatest common divisor of a nonempty list of 
nonnegative integers 


(d) 1cm*, which finds the least common multiple of a nonempty list of non- 
negative integers. 


(e) sum, which finds the sum of a nonempty list of integers 


(f) product, which finds the product of a nonempty list of integers 


(exercise transcripts 178a) += 
-> (sum '(1 2 3 4)) 


10 

-> (product '(1 2 3 4)) 
24 

-> (max* '(1 2 3 4)) 

4 

-> (lem* '(1 2 3 4)) 
12 


(g) mkpairfn, which when applied to an argument v, returns a function 
that when applied to a list of lists, places v in front of each element: 
(exercise transcripts 178a) += 

-> ((mkpairfn ta) '(() (b c) (d) (Ce f)))) 
((a) (a bc) (a d) (a Ce f))) 


All seven functions can be defined by a sequence of definitions that includes 
only one define, one lambda, and seven val bindings. Try it. 


Maps and folds with list results. Use map, curry, fold1, and foldr to define the 
following functions: 


(a) append, which appends two lists 
(b) snoc, which is cons spelled backwards, and which adds an S-expression 
to the end of a list: 


(exercise transcripts 178a) += 
-> (snoc 'a '(b c d)) 
(b c d a) 


(c) reverse, which reverses a list 


(d) insertion-sort, which sorts a list of numbers 
When implementing insertion-sort, take insert as given in chunk 101a. 


Folds for everything. Use foldr or foldl to implement map, filter, exists?, 
and all?. Itis OK if some of these functions do more work than their official 
versions, as long as they produce the same answers. 


For the best possible solution, define functions that no civilized wScheme 
program can distinguish from the originals. (A civilized program may exe- 
cute any code, including set, butit may not change the functions in the initial 
basis.) 


2.16.10 Functions as arguments 


31. 


32. 


33. 


34. 


Selections of sublists. Function takewhile takes a predicate and a list and re- 
turns the longest prefix of the list in which every element satisfies the pred- 
icate. Function dropwhile removes the longest prefix and returns whatever 
is left over. 
(exercise transcripts 178a) += 

-> (define even? (x) (= (mod x 2) 0)) 

-> (takewhile even? '(2 467 8 10 12)) 

(2 4 6) 

-> (dropwhile even? '(2 467 8 10 12)) 

(7 8 10 12) 


Implement takewhile and dropwhile. 


(You might also look at Exercise 26, which asks you to prove a basic law about 
takewhile and dropwhile.) 


Lexicographic comparison. All sorts of sorting operations use lexicographic 
orderings, which are a generalization of alphabetical order. For example, 
to sort dates, we might compare first months, then days: 
(transcript 95a) += 
-> (record date (month day)) 
-> (define date< (di d2) 
(if (!= (date-month di) (date-month d2)) 
(< (date-month d1) (date-month d2)) 
(< (date-day di) (date-day d2)))) 
-> (val dates 
(let ([date-of-pair (lambda (p) (make-date (car p) (cadr p)))]) 
(map date-of-pair '((4 5) (2 9) (3 3) (8 1) (2 7))))) 
-> ((mk-insertion-sort date<) dates) 


((make-date 2 7) (make-date 2 9) (make-date 3 3) (make-date 4 5) (make-date 8 1)) 


Generalize the date< function by writing a higher-order function lex-<* that 
compares lists of differing lengths lexicographically. It should take as a pa- 
rameter an ordering on the elements of the list. Avoid making any assump- 
tions about the elements, other than that they can be ordered by the param- 
eter. 
(exercise transcripts 178a) += 

-> (val alpha-< (lex-<* <)) 

-> (alpha-< '(4 15 7) '(4 15 7 13 1)) 


-> (alpha-< '(4 15 7) '(4 15 5)) 


This particular example illustrates alphabetical ordering. To see the relation- 
ship, translate the numbers to letters: the two results above say DOG < DOGMA 
and DOG < DOE. 


Binary search trees, polymorphically. Write a higher-order implementation of 
binary-search trees. Use the third style of polymorphism described in Sec- 
tion 2.9.1. Thatis, write a function specialized-search that takes a compar- 
ison function as argument and returns an association list which associates 
symbols lookup and insert to the corresponding functions. 


Generalized dot product. Exercise 5 asks for a dot-product function. General- 
ize this pattern of computation into a “fold-like” function foldr-pair, which 
operates on two lists of the same length. (This function is primitive in APL.) 
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35. 


36. 


Generalized preorder traversal. Function preorder in Section 2.4.2 is not so 
useful if, for example, one wants to perform some other computation on 
a tree, like finding its height. By analogy with foldl and foldr, define 
fold-preorder. In addition to the tree, it should take two arguments: a func- 
tion to be applied to internal nodes, and a value to be used in place of the 
empty tree. Function fold-preorder can be used to get the labels and the 
height of the example tree on page 109: 

(exercise transcripts 178a) += 


-> (fold-preorder 
(lambda (tag left right) (cons tag (append left right))) 
me) 
example-sym-tree) 
(ABCODEF GH TI) 
-> (define tree-height (t) 
(fold-preorder (lambda (tag left right) (+ 1 (max left right))) 
0 
t)) 
-> (tree-height example-sym-tree) 
4 


Generalized al1?, with predicates of two or three arguments. In this problem 
you generalize function all? so it can work with all pairs from two lists or 
all triples from three lists. For example, all-pairs? might be used with this 
length-append-1law function to confirm that the law holds for 25 combina- 
tions of inputs: 
(exercise transcripts 178a) += 
-> (define length-append-law (xs ys) 
(= (length (append xs ys)) 
(+ (length xs) (length ys)))) 
-> (all-pairs? length-append-law 
'((a bc) (singleton) () (814159) (2718 2 8)) 
'c(1 2 3) () (elephants got big feet) (z) (w x))) 
#t 


Generalize al1? to combinations of values drawn from two or three lists: 


(a) Define function all-pairs?, which tests its first argument on all pairs 
of values taken from its second two arguments. Here are some more 
example calls: 

(exercise transcripts 178a) += 
-> (all-pairs? < '(1 2 3) '(45 6 7)) 
#t 
-> (all-pairs? < '(1 2 3) '(45 6 2)) 
#f 


When the second test fails, the fault could be in the implementation or 
the specification. To simplify diagnosis, I expand the < function: 
(exercise transcripts 178a) += 

-> (all-pairs? (lambda (n m) (< mn)) '(1 2 3) '(45 6 2)) 

#f 


It is definitely not an algebraic law that for all mand n,m <n, so the 
fault here lies in the specification, not in the implementation of <. 


(b) Define function all-triples?, which works like all-pairs? but can 
test laws like the associativity of append. 


(exercise transcripts 178a) += 
-> (define a-a-law (xs ys zs) 77 append/append law 
(equal? (append xs (append ys zs)) 
(append (append xs ys) zs))) 
-> (all-triples? a-a-law '((a) () (b c)) '((1 2) (3)) '((4 5 6))) 
#t 


2.16.11 Functions as results 


37. 


38. 


39. 


Using lambda: Creation and combination of fault-detection functions. This prob- 
lem models a real-life fault detector for Web input. An input to a Web form 
is represented as an association list, and a detector is a function that takes an 
input as argument, then returns a (possibly empty) list of faults. A fault is 
represented as a symbol—typically the name of an input field that is unac- 
ceptable. 


Define the following functions, each of which is either a detector or a detec- 
tor builder: 


(a) Function faults/none is a detector that always returns the empty list 
of faults. 


(b) Function faults/always takes one argument (a fault F’), and it returns 
a detector that finds fault F' in every input. 


(c) Function faults/equal takes two arguments, a key k anda value v, and 
itreturns a detector that finds fault k ifthe input binds k to v. Otherwise 
it finds no faults. 


(d) Function faults/union takes two detectors d, and dz as arguments. 
It returns a detector that, when applied to an input, returns all the faults 
found by detector d, and also all the faults found by detector dz. 


Sets represented as functions. In just about any language, sets can be repre- 
sented as lists, but in Scheme, because functions are first class, a set can be 
represented as a function. This function, called the characteristic function, 
is the function that returns #t when given an element of the set and #f oth- 
erwise. For example, the empty set is represented by a function that always 
returns #f, and membership test is by function application: 
(exercise transcripts 178a) += 

-> (val emptyset (lambda (x) #f)) 

-> (define member? (x s) (Ss x)) 


Representing each set by its characteristic function, solve the following prob- 
lems: 

(a) Define set evens, which contains all the even integers. 

(b) Define set two-digits, which contains all two-digit (positive) numbers. 


(c) Implement add-element, union, inter, and diff. The set (diff s1s2) 
is the set that contains every element of s1 that is not also in s2. 


(d) Implement the third style of polymorphism (page 134). 


Lists reimplemented using just lambda. This exercise explores the power of 
lambda, which can do more than you might have expected. 


(a) Iclaim above that any implementation of cons, car, and cdr is accept- 
able provided it satisfies the list laws in Section 2.5.1. Define cons, car, 
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(b) 
(c) 


cdr, and empty-list using only if, lambda, function application, the 
primitive =, and the literals #t and #f. Your implementations should 
pass this test: 
(exercise transcripts 178a) += 
-> (define nth (n xs) 
(if (= n 1) 
(car xs) 
(nth (- n 1) (cdr xs)))) 
nth 
-> (val ordinals (cons '1st (cons '2nd (cons '3rd empty-list)))) 
-> (nth 2 ordinals) 
2nd 
-> (nth 3 ordinals) 
3rd 


Under the same restrictions, define nu11?. 


Now, using only lambda and function application, define cons, car, cdr, 
null?, and empty-list. Don’t use if, =, or any literal values. 

The hard part is implementing nu11?, because you can’t use the stan- 
dard representation of Booleans. Instead, you have to invent a new rep- 
resentation of truth and falsehood. This new representation won't sup- 
port the standard if, so you have to develop an alternative, and you 
have to use that alternative in place of if. For inspiration, you might 
look at the definition of binds? in chunk 141b, which uses find-c. 
If there were no such thing as a Boolean, how would you adapt the 
binds? function? 

Equipped with your alternative to if and a new representation of 
Booleans, implement nul1? using only lambda and function appli- 
cation. And explain what a caller of null? should write instead of 
(if (null? x) e, €2). 


40. Mutable reference cells implemented using lambda. Exercise 58 invites you to 
add mutation to the Scheme interpreter by adding primitives set-car! and 
set-cdr! But if you want to program with mutation, you don’t need new 
primitives—lambda is enough. 


A mutable container that holds one value is called a mutable reference cell. De- 
sign a representation of mutable reference cells in pScheme, and implement 
in wScheme, without modifying the interpreter, these new functions: 


(a) 


(b) 


(c) 


Function make-ref takes one argument v and returns a fresh, mutable 
reference cell that initially contains v. The mutable reference cell re- 


turned by make-ref is distinct from all other mutable locations. 


Function ref-get takes one argument, which is a mutable reference 
cell, and returns its current contents. 

Function ref-set! takes two arguments, a mutable reference cell and 
a value, and it updates the mutable reference cell so it holds the value. 
It also returns the value. 


(exercise transcripts 178a) += 


=> 
=> 
3 

-> 
99 
> 
99 


(val r (make-ref 3)) 
(ref-get r) 


(ref-set! r 99) 


(ref-get r) 


(exercise transcripts 178a) += 
-> (define inc (r) 
(ref-set! r (+ 1 (ref-get r)))) 
-> (inc r) 
100 


2.16.12 Continuations 


41. Continuation-passing style for a Boolean-formula solver. Generalize the solver in 
Section 2.10.2 to handle any formula, where a formula is one of the following: 
« Asymbol, which stands for a variable 
* The list (not f), where f is a formula 
* The list (and f; ... fn), where f),..., fn are formulas 
* The list (or f; ... fn), where f1,..., fn are formulas 
Mathematically, the set of formulas F' is the smallest set satisfying this equa- 
tion: 
F=SYM 
U{ (list2 'not f) | fe F} 
U{ (cons 'and fs) | fs € LIST (F) } 
U{ (cons 'or fs) | fs € LIST(F) }. 


Define function find-formula-true-asst, which, given a satisfiable for- 
mula in this form, finds a satisfying assignment—that is, a mapping of vari- 
ables to Booleans that makes the formula true. Remember De Morgan’s laws, 
one of which is mentioned on page 131. 


Function find-formula-true-asst should expect three arguments: a for- 
mula, a failure continuation, and a success continuation. When it is called, 
as in (find-formula-true-asst f fail succ), it should try to find a satisfy- 
ing assignment for formula f. If it finds a satisfying assignment, it should 
call succ, passing both the satisfying assignment (as an association list) and 
a resume continuation. If it fails to find a satisfying assignment, it should 
call (fail). 

You'll be able to use the ideas in Section 2.10.2, but probably not the code. In- 
stead, try using letrec to define the following mutually recursive functions: 


* (find-formula-asst formula bool cur fail succeed) extends current 
assignment cur to find an assignment that makes the single formula 
equal to bool. 


* (find-all-asst formulas bool cur fail succeed) extends cur to find 
an assignment that makes every formula in the list formulas equal to 
bool. 


* (find-any-asst formulas bool cur fail succeed) extends cur to find 
an assignment that makes any one of the formulas equal to bool. 
In all the functions above, bool is #t or #f. 


Solve the problem in two parts: 


(a) Write algebraic laws for all four recommended functions. 
(b) Write the code. 


car 
cdr 
cons 
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io redomp  plx)=l _(¢,p,0) F (,0") 
(sET(x,e),p,0) 4} (v,o'{£ ++ v}) 
MKCLOSURE 
L1,..-,%y all distinct 
(LAMBDA((1, Bane Pays €), P; a) 1 ((LAMBDA((x1, ise :En)}, e), p ), a) 
APPLYCLOSURE 


f1,...,ln ¢ dom oy (and all distinct) 


(e, p,o) |) ((LAMBDA((21,.--,%n),€c); Pe), Oo) 
(e1,P, 20) ¥ (v1, 01) 


(En, P; On—1) 4 (Un; On) 


(€e; Pc{X1 +> C1,...,8n Enh, on{Ar > U1,-.-,n Unt) I du, 0") 
(APPLY(e, El,--- ,€n); P; a) (v, a) 
LITERAL 


(LITERAL(v), 9,0) |) (v, 0) 


IFTRUE 
(e1, P; o) a (v1, a’) U1 # BOOLV(#f ) (ea, P; a’) a (v2, a’) 
(IF(e1, €2, €3); P; o) 1 (v2, a”) 


IFFALSE 
(e1, Pp; o) a (v1, a") U= BOOLV(#f ) (e3, P; a") a (v3, a’) 
(IF(e1, €2; €3), P; o) 1 (v3, go) 


WHILEITERATE 
(e1, P; o) 1 (v1, a’) U1 # BOOLV(#f ) 
(eo, P; a’) 1 (v2, ol) (WHILE(€1, €2), P; oa") 1 (v3, ge) 
(WHILE(€1, €2), P; a) 1 (v3, o") 


WHILEEND 
(e1,p,0) | (v1,0) vy = BOOLV(#f) 


(WHILE(€1, €2), p,0) |) (BOOLV(#f), 0’) 


Figure 2.9: Summary of operational semantics (expressions, except LET forms, 
BEGIN, and primitives) 


(e, p,7) 4 (v, 0) 


LET 
Y1,..-,%y all distinct 
l1,...,4n ¢ domo, (and all distinct) 
09 =O 
(€1, P; 00) V (v1, 01) 
(Cn 0s0g 1) a (Un; On) 
(e, p{@1 > ae sey En > La lsOn vet > UL,++ by > Un }) ay (v, 0’) 
(LET((%1, €1, sae baer €), Ps o) a (v, a’) 
LETSTAR 
po =p 00 =O 


(€1,P0,00) 4 (v1,00) 1 €domag pi = po{t1 4 Li} a1 =a9{f1 4 vi} 


(en, Pn-1; On-1) A (Un; on-1) 


ln ¢ domo}, pn = Pn-1{@n > ln} On = eee es +> Un } 
(€, Pn, On) al) (v, 0") 


(LETSTAR((21, E1,+++5Un, En), €); P; a) 1 (v, a) 
LETREC 
£1,...,€n € domo (and all distinct) 
L1,..-+,%y all distinct 
e; has the form LAMBDA(---), 1 <i<n 
pl = p{zi Hy £1,...5 8p, > £,} 
09 = o{f; + unspecified, ..., 0, + unspecified} 


(e1, p’, 00) 1 (v1, 01) 


(ens P!sOn—1) I (Gn on) 


(e, p!, Onf{ ly 4 U1,.--,£n 2 Un}) Yuya! 
(LETREC((21, €1,--+,Un; En), ey P; o) (v, a") 
BEGIN 


(€1, 2,90) al (v1, 01) 
(€2, P,01) 1 (v2, 02) 


EMPTYBEGIN 
(en, P; On-1) a (Un; On) 


(BEGIN(), P; o) 1 (BOOLV(#f ), a) (BEGIN(€1, EQ,++ +5 en) Pp; oy) 1 (Un, On) 


Figure 2.10: Summary of operational semantics (LET forms and BEGIN) 
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APPLYADD 
(€, 0, 00) 4} (PRIMITIVE(+), 01) 
(e1, p, 71) 4) (NUMBER(n), 72) 
(€,p,0) 4 (v, 0) eee an 


(APPLY(e, €1, €2), P, 70) 4) (NUMBER(n + m), 03) 

EQNUMBER EQSYMBOL 
m = n (identity of numbers) s = s’ (identity of symbols) 
NUMBER(n) = NUMBER(m) SYMBOL(s) = SYMBOL(s’) 

EQBOOL EQNIL 

b =U’ (identity of Booleans) 

BOOLV(b) = BOOLV(b’) NIL = NIL 
APPLYEQTRUE 


(e, P, 00) 4) (PRIMITIVE(=), 71) 
(e1,p,01) 4 (v1, 02) 


(€2, P,02) 4 (v2, 03) 
Ui = v2 


(APPLY(e, €1, €2), P, Jo) 4) (BOOLV(#t), 3) 


APPLYEQFALSE 
(€, P, Jo) \) (PRIMITIVE(=), 71) 
(e1, P; 01) 4 (v1, 02) 
(€2, P, 2) 4} (v2, 03) 
VU, # Ve (i.e., no proof of v1 = v2) 
(APPLY(e, €1, €2), P, 00) 4 (BOOLV(#f), 73) 


APPLYPRINTLN 
(e, P, 00) 4} (PRIMITIVE(println), 01) 
(e1, P; 01) V (v, 72) 
(APPLY(€,€1),P;00) | (v,02) while printing v 


APPLYPRINTU 
(e, 0,00) 4} (PRIMITIVE(printu), o1) 
(€1, p, 01) 4) (NUMBER(7), 02) 
0<n< 2!6 
(APPLY(e, €1),P,00) 4) (NUMBER(n),02) — while printing the UTF-8 coding of n 


CONS 
(€, P, 00) \- (PRIMITIVE(cons), 01) 
(e1, p; 01) 4 (v1, 72) 
(€2, P, 02) 4} (v2, 03) 
é, ¢ doma3 ly ¢ domaz3 lL, 4 by 
(APPLY(e, €1, €2), 0,00) |) (PAIR(61, C2), 03 {01 9 U1, £2 + V2}) 


CAR CDR 
(e, P, 00) ) (PRIMITIVE(car), 01) (e, P, 00) 4} (PRIMITIVE(cdr), 01) 
(e1, p01) Y (PAIR(41, £2), 02) (e1, 0,01) Ye (PAIR(é1, £2), 02) 
(APPLY(e, €1), 2,00) 4) (o2(41), 02) (APPLY(€, €1), 0,00) 4 (a2(¢2), a2) 


Figure 2.11: Summary of operational semantics (primitives) 


2.16.13 Semantics, laws, and proof 


To help you with the operational-semantics exercises, the rules of 4«Scheme’s oper- 
ational semantics are summarized in Figures 2.9 to 2.11 on pages 190 to 192. 


42. Proof or refutation of algebraic laws for cdr. Algebraic laws can often be proven 


43. 


44. 


45. 


by appeal to other algebraic laws, but eventually some proofs have to ap- 
peal to the operational semantics. This exercise explores the algebraic law 
for cdr. 


(a) The operational semantics for jsScheme includes rules for cons, car, 
and cdr. Assuming that x and xs are variables and are defined in p, use 
the operational semantics to prove that 


(cdr (cons x xs)) = xs 


(b) Use the operational semantics to prove or disprove the following con- 
jecture: if e; and e2 are arbitrary expressions, then in any context in 
which the evaluation of e; terminates and the evaluation of eg termi- 
nates, the evaluation of (cdr (cons e€; €2)) terminates, and 


(cdr (cons €; €2)) = €2 


The conjecture says that in any state, for any e; and €2, evaluating 
(cdr (cons €; €2)) produces the same value as evaluating e2 would 
have. 


Proof of an algebraic law for if. uScheme’s if expressions participate in many 
algebraic laws. Use the operational semantics to prove that 


(if e1 (if e2 €3 e4) (if eb eg e4)) = Cif (if e1 €2 eb) €3 4) 


Proof of validity of desugaring for let. Section 2.13.1 claims that let can be 
desugared into lambda: 


(let ([%1 €1]--: [%n €n]) €) = (Clambda (41 ++: Yn) e) €1 +** En). 


Using the operational semantics, prove that the claim is a good one for the 
case where n = 1. That is, prove that for any 71, €1, e, p, anda, if 


(LET((£1, €1), e), Pp; a) a (v, a’), 
then there exists a 0” such that 
(APPLY(LAMBDA((21),€),€1), 9,0) 4 (v,o””). 


Furthermore, show that if the choice of 4; ¢ doma is made in same way in 
both derivations, 0’ and o” are the same. 


Proof of validity of desugaring for let*. Section 2.13.1 claims that let* can be 
desugared as follows: 


(let* () e) 
(let* ([%1 €1] +++ [@pn €n]) ©) 
(let ([%1 €1]) (let* ([%2 €2] +++ [Xn €n]) €)) 


He [le 
fav) 


Using the same technique as in Exercise 44, prove that these rules are a good 
desugaring of let* into let. 
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DEFINEOLDGLOBAL 
x € dom p 


(, p27) 4 (vs 0") 
(vaL(x,e), p,o) + (p,o'{p(x) + v}) 


(d,p,0) + (p',0') 


DEFINENEWGLOBAL 
Scheme, « ¢ dom p é¢ domo 
S-expressions, and (e, p{a +> l},0{ +> unspecified}) |) (uv, 0’) 
first-class functions (waL(2,€),p.0) (pla O},0/{0r> oF) 
194 DEFINEFUNCTION 
(VAL(f, LAMBDA((71,..-,2n),€)),P,0) > (p', 0’) 
(DEFINE(f, (@1,.--,2n),€),p,0) > (p’, 0") 
EVALEXP 


(vAL(it,e),p,0) — (p’, a") 


(ExP(e), p,0) — (p',0") 


Figure 2.12: Summary of operational semantics (definitions) 


2.16.14 Semantics and design: Using the operational semantics to explore lan- 
guage design 


46. Alternate semantics for val. In both Scheme and uScheme, when val’s left- 
hand side is already bound, val behaves like set. If val instead always cre- 
ated a new binding, the semantics would be simpler. 


(a) Express the operational semantics of such a val by writing a DEFINE- 
GLOBAL rule. 


(b) Write a Scheme program that detects whether val uses the Scheme 
semantics or the new semantics. Explain how it works. 


(c) Compare the two ways of defining val. Think about how they affect 
code and coding style. Which design do you prefer, and why? 


47. Sensible restrictions on recursive val. The behavior of the DEFINENEWGLOBAL 
rule may strike you as rather odd, as it permits a “definition” like 
(transcript 95a) += 
-> (val u u) 


for a previously undefined u. The definition is valid, and u has a value, al- 
though the value is not specified. Similar behavior is typical of a number of 
dynamically typed languages, such as Awk, Icon, and Perl, in which a new 
variable—with a well-specified value, even—can be called into existence just 
by referring to it. 


In wScheme, the DEFINENEWGLOBAL rule makes it easy to define recursive 
functions, as explained on page 151. But you might prefer a semantics in 
which whenever u ¢ dom p, (val uu) is rejected. 
(imaginary transcript 194b)= 

-> (val u u) 

Run-time error: variable u not found 


Rewrite the semantics of jsScheme so that (val u u) and similarly disturbing 
expressions are rejected, but it is still possible to define recursive functions. 


48. 


49. 


50. 


Semantics in which every variable is always defined. jsScheme’s val defini- 
tion distinguishes an undefined global variable from a global variable that 
is bound to the empty list. Suppose this distinction is eliminated, and that an 
undefined global variable behaves exactly as if it were bound to the empty 
list. Is it possible to write a short wScheme program that gives a different an- 
swer under the new treatment? If so, write such a program. If not, explain 
why not. 


Operational semantics for short-circuit &&. Section 2.13.3 proposes syntactic 
sugar for short-circuit conditionals. To know if the syntactic sugar is any 
good, we have to have a semantics in mind. Use rules of operational seman- 
tics to specify how && should behave. That is, pretending that binary short- 
circuit && is actual abstract syntax and that (&& e1 €2) is a valid expression 
of Scheme, write rules for the evaluation of && expressions. 


Operational semantics of mutation. Write rules of operational semantics for 
full Scheme primitives set-car! and set-cdr!, which mutate locations in 
cons cells. To get started, revisit the rules for CONS, CAR, and CDR on 
page 151. 


2.16.15 Metatheory 


51. 


52. 


Proof that variables don’t alias. Use the operational semantics to prove that 
variables in Scheme cannot alias. That is, prove that the evaluation of a 
pScheme program never constructs an environment p such that x and y are 
both defined in p, x 4 y, and p(x) = p(y). 

Hint: It will help to prove that any location in the range of p is also in the 


domain of o. 


Safe extension of environments. Show that an environment can be extended 
with fresh variables without changing the results of evaluating an expres- 
sion. In more detail, 

* You are given e and p such that (e, p,o) 4) (v,o1). 


* You are given p’ such that dom p C dom p’, and for any x ine, p’(x) = 


p(z). 
* You are given o’ such that domo C domo’, and for any  € domo, 
a’ (£) = o(@). 


Prove that there exists a /, such that (e, p’,a’) |) (v,o}), and that for 
any  € doma, o;(£) = a1 (2). 


Use structural induction on the derivation of (e, p, 0) 4) (v,o1). 


(This exercise is related to Exercise 9 on page 324 in Chapter 5.) 


2.16.16 Implementing new syntax and syntactic sugar 


53. 


Syntactic sugar for short-circuit conditionals. In full Scheme, and and or are 
macros that behave like the variadic && and || operators defined in Sec- 
tion 2.13.3. 


(and) #t 
(and p) =p 
(and pj po --- Pn) = (if pi (and po... py) #f) 


Implementing or requires hygiene: you must find a fresh variable x that does 
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not appear in any e€;. 


(or) = tf 
(or e) =e 
(or ey ++: €n) = (let ([v e1]) (if ez (or eg --+ €n))), 
where x does not appear in any e;. 
Scheme, Reimplement jScheme’s and and or as follows: 


S-expressions, and 


Secs lass Hines (a) Remove and from the initial basis of pzScheme. Using the laws above, 


and emulating the example in Section G.7 (page S209), add a variadic, 
196 short-circuit and to Scheme as syntactic sugar. 


(b) Write an auxiliary function that is given a list of expressions and returns 
a variable x that does not appear in any of the expressions. 


(c) Remove or from the initial basis of jzScheme, and using the laws above 
and your auxiliary function, add a variadic, short-ciruit or to p:Scheme 
as syntactic sugar. 


To develop your understanding, and also to test your work, add two more 
parts: 


(d) Write an expression of ~Scheme that evaluates without error using 
both the original and and the new and, but produces different values 
depending on which version of and is used. 


(e) Write an expression of jScheme that evaluates without error using both 
the original or and the new or, but produces different values depending 
on which version of or is used. 


54. Syntactic sugar for records. Implement the syntactic sugar for record de- 
scribed in Section 2.13.6, according to these rules: 


(recordr (fi «++ fn)) = 
(define make-r (%1 +--+ Yn) 

(cons 'make-7r (cons x; (cons:-: (cons Z, '()))))) 
(define r? (x) (&& (pair? x) (= (car x) 'make-7r) ---)) 
(define r-fi (x) (if (vr? x) (car (cdr x)) (error :-:))) 
(define r-fe (x) (if (7? x) (car (cdr (cdr x))) (Cerror::--))) 


(define r-fn (x) (if (7? x) 
(car (cdr (cdr:-- (cdr x)))) 
(error:-:))) 


This exercise requires a lot of code. To organize it, I use these tricks: 


* The record definition desugars into a list of definitions. It’s not shown 
in the chapter, but wScheme has a hidden, internal mkDefs function 
that turns a list of definitions into a single definition. I build the list of 
definitions like this: 


(functions for desugaring record definitions 196)= 
Deflist desugarRecord(Name recname, Namelist fieldnames) ¢ 
return mkDL(recordConstructor(recname, fieldnames), 
mkDL(recordPredicate(recname, fieldnames), 
recordAccessors(recname, 0, fieldnames))); 


* I build syntax for calls to the primitives cons, car, cdr, and pair?. 
For each of these Scheme primitives, I define a C function, and it calls 
the literal primitive directly, like this: 

(functions for desugaring record definitions 196) += 


static Exp carexp(Exp e) { 
return mkApply(mkLiteral(mkPrimitive(CAR, unary)), mkEL(e, NULL)); 


3 
* I define an auxiliary C function that generates uScheme code that ap- $2.16 
plies cdr to a list a given number of times. Exercises 
* My C code builds syntax for a constructor function, a type predicate, 197 


and accessor functions. For each kind of function, I first build an ex- 
pression that represents the body of the function, which I put in a local 
variable called body. I then use body in the Def that I return. 


55. Quasiquotation. In Section 2.7.1, I put counter operations into a record. Anal- 


ternative is to put them into an association list: 
(transcript 95a) += 
-> (val resettable-counter-from 
(lambda (x) ; create a counter 
(liste 
(liste 'step (lambda () (set x (+ x 1)))) 
(liste 'reset (lambda () (set x 0)))))) 


Full Scheme offers a nicer way to write association lists: 
(fantasy transcript 197c)= 
-> (val resettable-counter-from 
(lambda (x) ; create a counter 
(quasiquote ((step (unquote (lambda () (set x (+ x 1))))) 
(reset (unquote (lambda () (set x 0)))))))) 


The quasiquote form works like the quote form—which is normally written 
using the tick mark '—except that it recognizes unquote, and the unquoted 
expression is evaluated. 


It might not be obvious that using quasiquote and unquote is any nicer than 
calling list2 (or full Scheme’s list). But full Scheme provides nice abbre- 
viations: just as quote is normally written with a tick mark, quasiquote and 
unquote are normally written with a backtick and a comma, respectively: 
(fantasy transcript 197c) += 
-> (val resettable-counter-from 
(lambda (x) ; create a counter 
‘((step , (lambda () (set x (+ x 1)))) 
(reset ,(lambda () (set x 0)))))) 
list2 B96 
(a) Look at the implementation of quote in Section L.5.1 (page S323), which 

relies on functions sSexp and parsesx on page $325. Emulating that 

code, write new functions sQuasi and parsequasi and use them to im- 

plement quasiquote and unquote. 


(b) Look at the implementation of getpar_in_context in chunk S170. Ex- 
tend the function so that when read_tick_as_quote is set, it not only 
reads ' as quote but also reads ‘ as quasiquote and , as unquote. 


2.16.17 Implementing new primitives 


56. 


57. 
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58. 


59. 


List construction. Add the new primitive list, which should accept any num- 
ber of arguments. 


Application to a list of arguments constructed dynamically. Add the new prim- 
itive apply, which takes as arguments a function and a list of values, and 
returns the results of applying the function to the values: 


(e, p, Jo) ) (PRIMITIVE(apply), 01) 
(e1, Pp, 01) aU (v, 02) 
(e2, P, 02) 4) (PAIR(£1, PAIR(€2,..., PAIR(€n, £))), 3) 
a3(£) = NIL o3(4i) =u, 1 <i<n 
(APPLY(LITERAL(v), LITERAL(v1), LITERAL(v2), ..., LITERAL(Un)), 0,03) 4} (v’, 04) 


(APPLY(e, €1, e2), Ps a0) al) (v', o4) 
(APPLY-AS-PRIMITIVE) 


Implementation of mutation. Add primitives set-car! and set-cdr!. Re- 
member that set-car! does not change the value the car field of a cons cell; 
it replaces the contents of the location that the car field points to. You'll have 
it right if your mutations are visible through different variables: 


(mutation transcript 198)= 


-> (val q '()) 

-> (val p '(a b c)) 
-> (set q p) 

-> (set-car! p 'x) 
-> (car q) 


Primitive to read S-expressions. Add a read primitive (as in Exercise 33 of 
Chapter 1). You may find it helpful to call p = getpar(...), followed by 
mkPL(mkAtom(strtoname("quote")), mkKPL(p, NULL)). 


Use the read primitive to build an interactive version of the metacircular in- 
terpreter in the Supplement. 


2.16.18 Improving the interpreter 


60. 


Call tracing. Instrument the interpreter so it traces calls and returns. When- 
ever a traced function is called, print its name (if any) and arguments. (Ifthe 
name of a function is not known, print a representation of its abstract syn- 
tax.) When a traced function returns, print the function and its result. 
To help users match calls with returns, indent each call and return should 
by an amount proportional to the number of pending calls not yet returned. 


Choose one of the following two methods to indicate which functions to 
trace: 


(a) Provide primitives to turn tracing of individual functions on and off. 


(b) Use variable &trace as a “trace count.” (Simply look it up in the cur- 
rent environment.) While &trace is bound to a location containing 
a nonzero number, each call and return should decrement the trace 
count and print a line. If the trace count is negative, tracing runs indef- 
initely. 


Test your work by tracing length as shown on page 99. Also trace sieve and 
remove-multiples. 


Printing the abstract syntax for a function provides good intuition, but it may 
be more helpful to print non-global functions in closure form. 


(c) When calling a closure, print it in closure form instead of printing its 
name. Which of the two methods is better? 
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Control operators and a 
small-step semantics: uScheme+ 


Formalizing a system in its own terms is now a familiar 
occupation. ... The formalization of a machine for 
evaluating expressions seems to have no precedent. 


Peter Landin, The Mechanical Evaluation of 
Expressions 


Chapter 2 presents applicative programming in uScheme. But wScheme doesn’t 
just support applicative programming; it also supports the procedural program- 
ming style described in Chapter 1. In particular, it provides while, set, and begin. 
In the procedural style, while and if account for most control flow. But loops typ- 
ically also use such control operators as break, continue, and return. These con- 
structs, as well as the less canonical try-catch and throw, don’t fit into the story 
about programming languages that we’ve been telling so far: 


* They aren't easy to implement using a recursive eval function. 


* They can’t be formalized using a judgment of the form (e,p,c) |} (v,a’). 
For example, evaluating break doesn’t produce a value. 


These troublesome constructs all involve control flow. 

In early high-level languages, control flow looked a lot like hardware. Typical 
hardware provides a goto instruction, which transfers control to a particular target 
point in the code, and a conditional goto, which transfers control only if some con- 
dition is satisfied. And in the 1950s, these same instructions were what you got in 
high-level languages like Fortran: 


GOTO target-label 
or 
IF condition GOTO target-label. 


But a program full of gotos can be hard to understand: in particular, the order in 
which the parts are executed need not have anything to do with the order in which 
they are written. The goto statement was eventually derided as “harmful” (Dijkstra 
1968), and goto was largely replaced with constructs like if and while. Using if 
and while, the order in which the parts are executed is determined by the order 
in which they are written, and it’s easy to see. The use of if and while as primary 
control-flow constructs is called structured programming. Structured programming 
was the most successful programming-language revolution of all time—in today’s 
languages, if and while are ubiquitous, and despite Donald Ervin Knuth’s (1974) 
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attempts to rehabilitate the goto statement, goto is frowned upon and is almost 
never used. 

But Knuth had a point. Using if and while exclusively can lead to convoluted 
code, especially in loops. To express loops more clearly, structured programming 
languages adapted: 


+ Languages added more looping constructs, including constructs like do- 
while, repeat-until, and several kinds of for loop. 


+ Languages added control operators like break, continue, and return. Each 
of these operators acts like a goto, but a goto with a predetermined target: 
break goes to the point immediately after its enclosing loop; continue goes 
to the point immediately before its enclosing loop; and return goes to the 
point in the calling function from which the current function was called. 


The action “go to a target” is exactly what is hard to implement in a recursive inter- 
preter and impossible to describe using a judgment of the form (e, p,c) |) (v,o’). 

Control operators are the subject of this chapter. The chapter presents not only 
break, continue, and return, but also try-catch and throw, which model excep- 
tional control flow between functions; and long-label and long-goto, which are 
low-level control operators that can implement all the others. These operators are 
specified and implemented using a new technique: an explicit representation of 
the context in which each expression is evaluated. Our representation is a stack. 
The stack is related to the C call stack of the recursive eval functions in Chapters 
1 and 2. It is also related to the path from an evaluation judgment to the root of 
a derivation. In our C code, the stack is a data structure, and in our operational 
semantics, the stack is a part of the state of the abstract machine. 

Most chapters in this book are oriented toward what you can do with new lan- 
guage ideas or new language features. But as you might guess from the talk about a 
stack, interpreters, and semantics, this chapter is oriented more toward how con- 
trol operators can be specified and implemented. And in Chapter 4, the implemen- 
tation is extended to show how civilized programming languages manage memory. 


3.1 THE uSCHEME-+ LANGUAGE 


Control operators are illustrated using an extension of wScheme called ~Scheme+, 
whose concrete syntax appears in Figure 3.1. 4sScheme-+ includes all of zScheme, 
plus control operators, plus syntactic sugar for procedural programming. The con- 
trol operators implement new program behaviors: “go to,” “throw,” and “catch.” 


* When (break) is evaluated inside a while loop, the interpreter goes to the 
point right after the loop. To evaluate (break) outside any loop is a checked 
error. 


* When (continue) is evaluated inside a while loop, the interpreter goes to 
the beginning of the loop and continues evaluating the loop (by testing its 
condition). To evaluate (continue) outside any loop is a checked error. 


* When (return e) is evaluated in a function’s body, the interpreter evalu- 
ates e to produce a value v, and that ends the evaluation of the function’s 
body; the function returns v. To evaluate (return e) outside the body of any 
function (for example, at top level) is a checked error. 


* When (throw L e) is evaluated, the interpreter evaluates e to produce a 
value v, and then it throws v to the most recently installed try-catch han- 
dler labeled with L. To throw a value v to L when no try-catch handler is 
installed for L is a checked run-time error. 


def = (val variable-name exp) 

exp 

(define function-name (formals) exp) 
(use file-name) 


unit-test 
unit-test = (check-expect exp exp) 
(check-assert exp) $3.1 
(check-error exp) The sScheme+ 
language 
exp = literal 508 


variable-name 

(set variable-name exp) 

(if exp exp exp) 

(while exp exp) 

(begin {exp}) 

(exp { exp} ) 

(let-keyword ( { [variable-name exp] } ) exp) 
(lambda (formals) exp) 
primitive 

(break) 

(continue) 

(return exp) 

(try-catch exp label-name exp) 
(throw label-name exp) 
(long-label label-name exp) 
(long-goto label-name exp) 


let-keyword ::= let | let* | letrec 


formals ::= {variable-name} 

literal = numeral | #t | #f | 'S-exp | (quote S-exp) 

S-exp ::= literal | symbol-name | ({S-exp}) 

primitive +|-|*|/|=|<|>|printin| print | printu| error 


| car | cdr | cons 
| number? | symbol? | pair? | null? | boolean? | function? 


numeral _::= token composed only of digits, possibly prefixed with a plus 
or minus sign 


*name ::= token that is not a bracket, a numeral, or one of the “re- 
served” words shown in typewriter font 


Figure 3.1: Concrete syntax of wScheme+ 


def xi (define type-exp function-name (formals) {exp}) 


exp = (while exp {exp}) 
| (let-keyword ( { [variable-name exp] } ) { exp} ) 
| (when exp {exp}) 
| 


(unless exp { exp}) 


Figure 3.2: Syntactic sugar that supports procedural programming 
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(when € €y -:: €n) = (if e (begine, --: e,) #f) 

(unless € €1 --: En) = (if e#f (begine, -:- €,)) 

(while ee, --: en) = (while e (begin e, -:: €,)) 
A 


(let-keyword (bindings) e; --- €,) = (let-keyword (bindings) (begin e, «++ €n)) 


Figure 3.3: Desugaring equations 


* In(try-catch e, L ep), expression ey is the body, name Lis the label, and 
€p is the handler. When the try-catch is evaluated, the interpreter evaluates 
the handler e;, to produce a value f, which must be a function. The inter- 
preter installs f as the most recent handler for label L, then determines the 
outcome of the try-catch expression by evaluating the body ep: 


- If e, evaluates normally to v, without throwing any value, the inter- 
preter uninstalls the handler f (reverting to the previous handler, if 
any). The try-catch expression returns v. 


- If, during the evaluation of ey, a value v is thrown to label L, and if f 
is the most recently installed try-catch handler, then the interpreter 
uninstalls the handler f (reverting to the previous handler, if any). This 
action is called catching v. The interpreter then applies f to v, and the 
try-catch expression does whatever the application (f v) does. 


- If expression e, throws a value v to some label L’ that is different 
from L, then the try-catch expression also throws v to L’. 


To evaluate (try-catch e, L e;,) when e;, evaluates to a non-function value 
is a checked run-time error. 


* When (long-goto L e) is evaluated, the interpreter evaluates e to produce 
a value v. Then it finds the youngest active long-label expression with the 
same label L. The interpreter goes to that long-label expression, which ter- 
minates immediately; it returns value v. To evaluate (long-goto L e) when 
no corresponding long-label expression is active is a checked run-time er- 
ror. 


When (long-label Le) is evaluated, the interpreter starts evaluating ex- 
pression e. If during that evaluation, e evaluates a long-goto with label L 
and value v, control immediately goes to the long-label expression, which 
produces value v. Otherwise, the long-label expression does whatever e 
does. 


The long-label form is a cousin of C’s setjmp, and the long-goto form is a 
cousin of C’s longjmp; the label L is analogous to a jmp_buf. The long-label and 
long-goto forms can be used in your wScheme+ programs, just like labels and 
goto statements in C, but they are meant to be used to implement the other control 
operators, as described in Section 3.4 below. 

The native forms of ;sScheme-+ are supplemented by the syntactic sugar shown 
in Figure 3.2. Sugar is called for because control operators are inherently procedu- 
ral: a control operator is a command that tells the computer to do something. And 
commands demand procedural programming; the very word “procedure” means 
a sequence of actions or commands. Using the syntactic sugar, sequences can be 
written without begin: the body of every function, loop, and let-expression is au- 
tomatically a sequence. Sequences also appear as the bodies of the one-way con- 
ditional forms when and unless. These forms are desugared using the rules shown 
in Figure 3.3. 


Armed with an informal understanding of the control operators, plus concrete 
syntax suitable for writing procedural code, we’re ready to see how wScheme-+’s 
control operators are used. 


3.2 PROCEDURAL PROGRAMMING WITH CONTROL OPERATORS 


Control operators can be studied in isolation, but in this section, procedural code 
that uses control operators is compared with functional code in the style of Chap- 
ter 2. I assume that you've seen procedural programming before, and I hope 
your experience includes break, continue, and return. The examples empha- 
size try-catch and throw; although they represent just one point in a large design 
space, they will help you think about design and implementation of language fea- 
tures for dealing with exceptional outcomes. 


3.2.1 Programming with break, continue, and return 


To compare procedural programming with functional programming, I use an old 
problem usually given to students who've studied just one semester of program- 
ming (Soloway 1986; Fisler 2014): 


Design a function called rainfall that computes average rainfall. 
The function consumes a list of numbers representing daily rainfall 
amounts as entered by a user. The list may contain the special num- 
ber 99999, which indicates that 99999 and all numbers that follow 
it should be ignored. Also, only nonnegative numbers are meaning- 
ful: a negative number represents a data-collection error, not a true 
rainfall amount, and it should also be ignored. The rainfall function 
should produce the average of the nonnegative values in the list up to 
the first 99999 (if it shows up). 


A functional solution to the rainfall problem 
If I’m a functional programmer, I might think about the problem like this: 


* Typical functional codes manipulate whole data structures: for the rainfall 
problem, whole lists. I care about lists like “everything up to 99999” and “all 
the nonnegative elements.” 


A list should be consumed by a recursive function. 


I might not have to write a new recursive function—maybe I can use an ex- 
isting one. Existing higher-order functions implement common recursions, 
and they’re easy to reuse and combine. For the rainfall problem, takewhile 
can grab list elements up to 99999, and filter can grab the nonnegative el- 
ements. Functions like takewhile and filter make it easy to write working 
code quickly, although they also make it less obvious how much computer 
time and memory are needed. 


Functions takewhile and filter might allocate cons cells, and that’s OK; 
a serious implementation of a functional language is designed for programs 
that allocate like crazy. 


My design plan looks like this: grab all the numbers up to (but not including) 99999, 
eliminate the negative ones, and return the sum of what's left, divided by its length. 
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“Grab up to” is takewhile and “eliminate” can be done using filter. 


206a. (transcript 206a)= 206b > 
-> (define rainfall-f (ns) 
(let* ([nonneg? (lambda (n) (>= n 0))] 
[ms (filter nonneg? (takewhile ((curry !=) 99999) ns))]) 
(/ (foldl + 0 ms) (length ms)))) 
-> (rainfall-f '(1 2 3 99999 4 5 6)) 


Control operators 2 
and a small-step -> (rainfall-f '(1 -1 2 -2 3 -3 6)) 
semantics: juScheme-+ 3 


-> (rainfall-f '(-1 -2 -3)) 
206 Run-time error: division by zero 
The code is good enough, but if the input list doesn’t contain any nonnegative 
numbers, I prefer a different error message. To avoid dividing by (length ms) when 
it might be zero, I first check if ms is empty. If so, I issue my own error message. 
My revised function looks like this: 
206b. (transcript 206a) += 1206a 207a> 
-> (define rainfall-f (ns) 
(let* ([nonneg? (lambda (n) (>= n 0))] 
[ms (filter nonneg? (takewhile ((curry !=) 99999) ns))]) 
(if (null? ms) 
Cerror 'rainfall-no-nonnegative-numbers) 
(/ (foldl + 0 ms) (length ms))))) 
-> (rainfall-f '(1 2 3)) 
e 
-> (rainfall-f '(99999 1 2 3)) 
Run-time error: rainfall-no-nonnegative-numbers 


A procedural solution to the rainfall problem 


If I’m a procedural programmer, I might think about the problem like this: 
* Typical procedural codes manipulate lists one thing at a time. 
* A list should be consumed by a loop, not by a recursive function. 


* Side effects are OK. The rainfall problem calls for an average, and just as in 
the functional solution, I'll need a total and a count. But in the procedural 
solution, the total and count can be kept in mutable variables, which can be 
initialized to zero and updated using set. 


* Procedural code usually avoids allocation, and for good reason: implementa- 
tions of procedural languages often assume that allocation is rare. The rain- 
fall problem consumes a list that is allocated on the heap, but its total and 
count are only numbers, and it returns a number. So it has no reason to al- 
locate. 


The challenge of the rainfall problem is what to do in the loop. The loop demands 
a nontrivial case analysis: the sentinel value 99999, if present, marks the end of 
the input, and other negative values should be ignored. These special cases can be 
managed using break and continue. My design plan looks like this: 

* Start with variables total and count set to zero. 


* Loop through the inputs, updating total and count as appropriate. 
* When the loop finishes, divide total by count. 


One draft is enough: 


207a. (transcript 206a) += <1206b 207b> 
-> (define rainfall-p (ns) 
(let* ([count 0] ; number of nonnegative numbers seen 
[total 0]) ; and their sum 
(while (not (null? ns)) 
(let* ([n (car ns)]) 
(set ns (cdr ns)) 
(when (= n 99999) 
(break) ) 
(when (<n 0) 
(continue) ) 
(set count (+ count 1)) 
(set total (+ total n)))) 
(if (= count 0) 
(error 'rainfall-no-nonnegative-numbers) 
(/ total count)))) 


Control operators break and continue simplify the code significantly (see Exer- 
cise 2), as does the syntactic sugar. And the code works as it should: 


207b. (transcript 206a) += <1207a 208a> 
-> (rainfall-p '(1 2 3 99999 4 5 6)) 
2 
-> (rainfall-p '(1 -1 2 -2 3 -3 6)) 
3 


-> (rainfall-p '(-1 -2 -3)) 
Run-time error: rainfall-no-nonnegative-numbers 


3.2.2 Programming with try-catch and throw 


If either rainfall or rainfall-p is given a list containing no nonnegative num- 
bers, it calls error, and the 4Scheme-+ code stops running. Suppose instead that 
we wish it to keep going. As a model, we could look to the C code that implements 
Impcore and psScheme. Calling runerror doesn’t mean that C code stops running; 
C code catches the error and continues (in the readevalprint function). How does 
it work? The C runerror function in chunk $182 calls longjmp, which transfers 
control to the setjmp in chunk $316c. 

The C functions setjmp and longjmp are low-level mechanisms: set jmp initial- 
izes a jmp_buf, and longjmp transfers control to it. And setjmp returns a code that 
distinguishes initialization from transfer. These mechanisms work, but a C pro- 
grammer has to think a lot about policy: how many jmp_bufs there should be, 
whether they are arranged in a stack, who is responsible for allocating and deallo- 
cating their memory, how to avoid using a stale jmp_buf, and so on. Many program- 
ming languages provide a mechanism that is easier to work with, usually called 
exceptions. They come with a lot of vocabulary. 


+ An exception signals that something has gone wrong or something unex- 
pected has happened. For example, a “not found” exception might signal 
that an expected name is not bound in an environment. 


Depending on the language, an exception may be a value, or it may be its 
own unique thing, distinct from values, variables, functions, and everything 
else. No matter what kind of thing it is, an exception can usually carry some 
additional information along with it, such as a name that wasn’t found. 


* When the bad or unexpected thing happens, the exception is thrown. (Some 
languages say raised or signaled.) 
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* When an exception is thrown, control is transferred to a handler; the han- 
dler catches the exception. And unlike break, continue, or return, throwing 
an exception can transfer control to a distant function: if there’s no handler 
in the function where the exception is thrown, the system looks for a handler 
in the calling function, and then the function that called the calling function, 
and so on. The system interrogates older and older active functions until it 
finds one that has an appropriate handler. 


What marks a handler as appropriate depends on the language. In some lan- 
guages, exceptions have names, and a handler is appropriate if it names the 
exception that is thrown. In other languages, exceptions are values, a han- 
dler names a type, and a handler is appropriate if the value thrown is com- 
patible with the named type. And in many languages, a handler can claim to 
be appropriate for all exceptions. 

To implement exceptions, a programming language needs three mechanisms: 


+ A way to create or name an exception to be thrown 
+ A way to throw the exception 


+ A way to introduce one or more handlers and to evaluate an expression 
within the context of those handlers. 


pScheme-+ uses the simplest mechanisms that illustrate the ideas: 


+ An exception is identified by name; any name can be an exception. 
+ An exception is thrown using throw. 


« A handler is introduced, and an expression is evaluated in its context, using 
try-catch. 
Using throw and try-catch, we can recover from errors in the rainfall functions. 


Rainfall with try-catch and throw 


In our rainfall-f and rainfall-p functions, nothing really needs to change, 
except instead of calling error, we would like to throw an exception. I could 
rewrite the code, but instead I use a dirty trick, which you can use with your own 
pScheme code: I overwrite the global variable error to contain a new function that, 
when called, throws the exception named :error.* 

208a. (transcript 206a) += <1207b 208b> 


-> (set error (lambda (msg) (throw :error msg))) 
<function> 


After this change, calling a rainfall function without any rainfalls produces a dif- 
ferent error message. 
208b. (transcript 206a) += 1208a 209a> 

-> (rainfall-p '()) 

Run-time error: long-goto :error with no active long-label for :error 
This message mentions long-goto and long-label because these are the mecha- 
nisms used to implement throw and try-catch (Section 3.4); the message means 
there’s no handler for the : error exception. 

A handler can be provided using try-catch. As a vastly oversimplified exam- 

ple, I define a prediction function. It predicts tomorrow’s rainfall by using the aver- 


1By convention, I identify each exception using a name that begins with a colon, but you can name 
an exception anything you like. 


age from rainfall-p, butif rainfall-p fails, it predicts a rainfall of zero. Function 
predicted-rainfall works even on inputs where rainfall-p fails. 


209a. (transcript 206a) += <1208b 209b> 
-> (define predicted-rainfall (data) 
(try-catch 
(rainfall-p data) ; this is evaluated in the scope of the handler 
serror ; this is the exception that the handler catches 
(lambda (_) 0) ; this is the handler 
)) 
-> (predicted-rainfall ‘(1 -1 2 -2 0 99999 6 -6)) 
1 
-> (predicted-rainfall '(99999 1 -1 2 -2 0 99999 6 -6)) 
0 
-> (rainfall-p ‘(99999 1-1 2 -2 0 99999 6 -6)) 


Run-time error: long-goto :error with no active long-label for :error 


More throwing and catching 


Exceptions are useful in many interfaces. As an example, an alternative to the 
search function find (Section 2.3.8, page 106) can throw the :not-found excep- 
tion if a key is not found. The implementation is written in procedural style, using 
while and return: 
209b. (transcript 206a) += 1209a 209c > 
-> (define find-or-throw (k alist) 
(while (not (null? alist)) 
(if (equal? k (alist-first-key alist)) 
(return (alist-first-attribute alist) ) 
(set alist (cdr alist)))) 
(throw :not-found k)) 


Function find-or-throw exemplifies the procedural way of consuming a list: 
it contains a loop but no recursion. It returns an attribute or throws the :not-found 
exception: 
209¢. (transcript 206a) += <1209b 209d> 
-> (find-or-throw 'E '((I Ching) (E coli))) 
coli 
-> (find-or-throw 'X '((I Ching) (E coli))) 


Run-time error: long-goto :not-found with no active long-label for :not-found 


-> (try-catch (find-or-throw 'X '((I Ching) (E coli))) 
:not-found 
(lambda (exn) (list2 'not-found exn))) 
(not-found X) 


These examples might remind you of the continuation-passing function find-c 
(page 136). That’s no accident; control operators and continuations both express 
non-local control flow. And each of these functions, find-or-throw and find-c, 
can easily be implemented in terms of the other. To implement find-or-throw 
using continuations, we supply a failure continuation that throws the exception. 
The success continuation is the identity function. 
209d. (transcript 206a) += <1209¢ 210a> 

-> (define alternate-find-or-throw (k alist) 

(find-c k alist (lambda (v) v) (lambda () (throw :not-found k)))) 
-> (alternate-find-or-throw 'E '((I Ching) (E coli))) 
coli 
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210a. (transcript 206a) += <1209d 210b> 
-> (alternate-find-or-throw 'X '((I Ching) (E coli))) 
Run-time error: long-goto :not-found with no active long-label for :not-found 
-> (try-catch (alternate-find-or-throw 'X '((I Ching) (E coli))) 
:not-found 
(lambda (x) (liste 'not-found x))) 
(not-found X) 
Control operators 
and a small-step 
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To implement find-c using the control operator, we install an exception han- 
dler that invokes the failure continuation. 
210b. (transcript 206a) += 1210a 215> 
210 -> (define alternate-find-c (k alist success-cont failure-cont) 
(try-catch (success-cont (find-or-throw k alist)) 


:not-found 
(lambda (key) (failure-cont)))) 
-> (alternate-find-c 'Hello '((Hello Dolly) (Goodnight Irene) ) 
(lambda (v) (liste 'the-answer-is v)) 
(lambda () 'the-key-was-not-found) ) 
(the-answer-is Dolly) 
-> (alternate-find-c 'Goodbye '((Hello Dolly) (Goodnight Irene)) 
(lambda (v) (liste 'the-answer-is v)) 
(lambda () 'the-key-was-not-found) ) 
the-key-was-not-found 


Continuations also turn out to be a fine way to specify the behavior of control 
operators (Stoy 1977; Allison 1986; Schmidt 1986). Sadly, continuation-based spec- 
ification techniques are beyond the scope of this book. 


3.3. OPERATIONAL SEMANTICS: EVALUATION USING A STACK 


A control operator’s behavior depends on what computations are active when it is 
evaluated. 


+ A break or continue must be evaluated inside an active while loop, which 
the control operator terminates or continues. 


+ Areturn must be evaluated inside an active function application, which the 
return terminates. 


« A throw must be evaluated during the evaluation of an active try-catch with 
the same label, whose handler the throw starts evaluating. 

In a recursive eval function like the ones used in Chapters 1 and 2, active compu- 
tations can’t easily be identified—a recursive C function cannot inspect its caller’s 
state, so the eval function can’t tell if a loop, function, or try-catch is waiting. 
In ~pScheme-+, the active computations aren't hidden on the C call stack; they 
are maintained on an explicit evaluation stack, which the interpreter can inspect. 
The evaluation stack is demonstrated in this section with an example, then used in 
Section 3.5 to write the operational semantics of puScheme-+. 

An evaluation stack is either empty, in which case it is written [], or it it is 
formed by pushing a frame F on top of another stack S, in which case it is writ- 
ten Ff’ :: S. The operator :: associates to the right, so for example if a stack has 
exactly four frames, it could be written out in full as Fy :: Fo :: F's :: Fy :: []. These 
frames are numbered in the order in which we see them when inspecting the stack, 
which is the reverse of the order in which they were pushed. 

Each individual frame F is an expression with a “hole” in it. The frame is “wait- 
ing” for the value of some expression, and the hole, which is written using the bullet 


symbol e, stands for a place where that value is expected to be plugged in. For ex- 
ample, the frame (+ @ 1) is waiting for a value that it plans to add 1 to. 

During computation, the evaluation stack changes, and it usually changes in 
the same way that the C call stack changes when the interpreter in Chapter 2 is 
running. For example, where Chapter 2’s interpreter calls eval, and an activation 
record is pushed onto the C call stack, this chapter’s interpreter pushes a frame onto 
the evaluation stack—and that frame is waiting for the result from eval. Where 
Chapter 2’s interpreter would return from eval, this chapter’s interpreter pops a 
frame off the evaluation stack, and it fills the hole in the frame with the value that 
Chapter 2’s eval would have returned.” 

The evaluation stack S is just part of an abstract machine. Like the abstract 
machines of Chapter 2, the abstract machine for sScheme-+ also includes an en- 
vironment p and a store 0. The zScheme+ abstract machine makes transitions 
between states of these two forms: 


(e, p,0,5') The machine is about to evaluate expression e; stack $ 
is waiting for the result. The machine’s next transition 
is determined by the syntactic form of the expression e. 


(v,p,0,S) The machine has just finished evaluating an expression 
to produce value v; it is about to plug v into the hole 
in the top frame of stack S. The machine’s next transi- 
tion is determined by the syntactic form of the stack S— 
usually by the form of the topmost frame—and possibly 
also by a property of v. 


The state’s first element, which is either e or v, is the current item. And an op- 
erational semantics based on transitions between states like these is an abstract- 
machine semantics. 

Below, the abstract-machine transitions are illustrated by comparing a stack- 
based evaluation, which uses this machine, with a recursive evaluation, which 
gradually fills in a derivation in the style of Chapters 1 and 2. Both evaluations 
use the expression 

(* (+ 10 1) 9). 


Each step of evaluation is presented in a four-part template numbered N, where 
N is the number of steps taken since the beginning: 


N| Narrative of recursive evaluation Partially traversed derivation of 
from Chapter 2. (e, p,o) | (u,a"). 
Narrative of stack-based evaluation. State of abstract machine with stack, 


either (e, p,0, S) or (v, p,0, 8). 


The recursive eval from Chapter 2 traverses a derivation tree node by node. Ina 
template, a partially traversed tree is indicated by the colors of the big-step judg- 
ments: a judgment whose subderivation is completely traversed is colored black, 
and a judgment whose subderivation is not yet traversed is colored gray. A judg- 
ment whose traversal by Chapter 2 eval is currently in progress is shown half and 


*The eval function isn’t special: any recursive function can be converted into a loop that uses an 
explicit stack. If you’ve seen this technique before, some of what’s in this section will be old news, 
and you can concentrate on what’s happening in the different kinds of semantics. If you haven't seen 
the technique before, be aware that it’s good for more than just semantics: it’s good for any recursive 
algorithm that needs very deep recursions. One of my favorite examples is depth-first search of a graph 
with millions of nodes. 
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half: black on the left and gray on the right. The colors can help you compare the 
progress of the two evaluations: if you follow a path from the uppermost call in 
progress down to the root of the derivation tree, you'll see that each judgment on 
the path corresponds to a frame on the stack. 

In the stack-based evaluation, each state in which the current item is an expres- 
sion is labeled ExP, and each state in which the current item is a value is labeled 
VALUE. And to make it extra easy to distinguish values from literal expressions, in 


this example only, values are written using an italic font, asin 99. 
Recursive evaluation starts by passing expression e = (* (+ 10 1) 9) toeval. 
Stack-based evaluation starts in a state in which the current item is the expression e 


and the stack is empty: 


0| Pass the expression € to eval. 


Make expression e the current item and 
make the stack empty. 


1| Call eval (via evallist) with the first 
argument of *. 


In the current expression, replace the 
first argument of * with a hole and push 
the resulting frame on the stack. The first 
argument becomes the current item. 


2| Call eval (via evallist) with the first 
argument of +. 


Replace the first argument of + with a 
hole and push the resulting frame on the 
stack. The first argument becomes the 
current item. 


3| Evaluate literal 10, returning 10 from 
eval. 


Evaluate literal 10, producing 10. The 
value 10 becomes the current item; the 
stack is unchanged. 


4| Call eval (via evallist) with the sec- 
ond argument of +. 


Pop the top frame off the stack; it is a 
call to + with a hole as the first argument 
and an expression as the second argu- 
ment. Replace the hole with the current 
value 10, and pull out the second argu- 
ment, replacing it with a new hole. Push 
the modified frame back on the stack. 
The second argument becomes the new 
current item. 


(10, p) Y 10 (1,p) 1 


((+ 101), p) ) 11 (9,p) 49 


(C* (+ 10 1) 9), p) 99 
EXP ((* (+ 10 1) 9), p,¢, []) 


(10, p) 4 10 (1, p) 1 


((+# 101), p) 4 11 (9, p) 49 


(C# (+ 10 1) 9), p) Ye 99 


EXP ((+ 10 1), p,0, (# @ 9) :: []) 


(10, e) {L 10 (1, p) 41 


((+# 101), p) | 11 (9,p) 9 


(C# (+ 10 1) 9), p) Ye 99 


EXP (10, p,0, (+¢@1) :: (€ @9) :: []) 


(10, p) ) 10 (1, p) 1 


((+# 101), p) 4 11 (9,p) 49 


(C* (+ 10 1) 9), p) 4 99 


VAL (10, p, 0, (+ @ 1) :: (#9) :: []) 


(10,p) 10 (1p) 


((+# 101), p) | 11 (9, p) 49 


(C# (+ 10 1) 9), p) 4 99 


EXP (1, p,0, (+ 10 @) :: (# @ 9) :: []) 


5| Evaluate literal 1, returning 1 from 
eval. 


The expression 1 is evaluated to 1, which 
becomes the new current item. The stack 
is unchanged. 


6| Function eval adds values 10 and 1, re- 
turning 11. 


Pop the top frame off the stack and fill 
its hole with the current value 1. The re- 
sulting expression is the complete call 
(+101). Replace the call with the re- 
sult 11, which becomes the current item. 


7| Call eval (via evallist) to evaluate the 
second argument of *. 


Pop the top frame off the stack; it is a call 
with a hole as the first argument and an 
expression as the second argument. Re- 
place the hole with the current value 11, 
and pull out the second argument, re- 
placing it with a new hole. Push the mod- 
ified frame back on the stack, and let the 
second argument become the new cur- 
rent item. 


8 | Evaluating 9 returns 9. 


The expression 9 is evaluated to 9, which 
becomes the new current item. The stack 
is unchanged. 


9 | Function eval multiplies 11 by 9, re- 
turning 99. 


Pop the top frame off the stack and fillthe 
hole with the current item 9. The result- 
ing expression is a complete call to the 
primitive *. The result of the multipli- 
cation is 99, which becomes the current 
item. 


(10,p) 10 (1, p) Y 1 


((+# 101), p) Y 11 (9, p) 9 


(C# (4 101) 9), p) YP 99 


VAL (1, p,0, (+ 10) :: (# @ 9) :: []) §3.4 
Operational 
semantics: 
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((+ 101), p) I 11 (9,p) 49 core language 


(C* (+ 10 1) 9), p) 4 99 
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VAL (11, p,0, (* @ 9) :: []) 


(10,p) 10 (1p) V1 


((# 101), p) Y 11 (9, p) 4 9 


(C# (4101) 9), p) YP 99 


EXP (9, p,0, (* 11 @) :: []) 


(10,p) 10 (1p) Yi 


((# 101), p) Y 11 (9,p) 4 9 


(C* (+ 10 1) 9), p) 4 99 
VAL (9, p, 0, (* 11 @) :: []) 


(10,p) 10  (1,p) Yi 


((# 101), p) Y 11 (9, p) 4 9 


((* (+ 10 1) 9), p) 4 99 


VAL (99, p, 0, []) 


After 9 steps, the current item is a value and the stack is empty, so (99, p, 0, []) isa 
valid state, and the result of evaluating the expression is 99. 


3.4 OPERATIONAL SEMANTICS: LOWERING TO A CORE LANGUAGE 


An abstract-machine semantics with an explicit evaluation stack suffers from an 
annoying drawback: it can require a lot of rules. Like the big-step semantics of 
Chapters 1 and 2, the abstract-machine semantics needs at least one rule for every 
form of expression. But in addition, it needs at least one rule for every form of 
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Table 3.4: Lowering rules 


Lowering rules for control operators 


(while e, €2) ~~» (long-label : break 

(while* e; (long-label :continue e2))) 
(break) ~~» (long-goto : break) 
(continue) ~» (long-goto :continue) 


(try-catch e; L eg) ~» (let ([h €2]) 
(long-label L (let ([x e1]) (lambda (_) x))) h) 
(throw L e) ~> (let ([x e]) (long-goto L (lambda (h) (hx)))) 


Lowering rules for lambda and return 


(lambda (x1 --- Yp) €) ~» (lambda* (x1 --+ @,,) (long-label :return e)) 
(return) ~~» (long-goto :return) 


Lowering rules for other expression forms 


(while™* e; €2) ~~ (if e; (begin eg (while* e; €2)) #f) 
(begin) ~» $f 

(begin e) ~e 

(begin €; €2:--) ~> (let ([% €1]) (begin e2---)) 

(let* () e) we 


(let* ([%1 €1] +++) e) ~» (let ([%1 €1]) Clet* (---) e€)) 


Variable h is not free in e;, and variable z is not free in any e;. 
Form lambda* behaves like lambda, except it is not lowered. 


stack frame—and there are about as many forms of stack frame as there are forms 
of expression. The drawback can be mitigated by reducing the number of forms of 
expression. To do that, some forms of expression are lowered to a core language. 

A core language is a subset that is sufficient to express everything in a full lan- 
guage. The full language is lowered to a core language by a process of rewriting 
expressions. It works much the same way as expanding syntactic sugar, except 
when a full language is lowered to a core language, the original syntax is usually 
kept around to be used in error messages. 

Core psScheme-+ includes long-label and long-goto forms, but not break, 
continue, try-catch, or throw forms—these forms are lowered into the core. Core 
pScheme-+ also omits begin and let* forms, which are lowered to let expressions. 
Finally, Core 4«zScheme-+ does include return; while return can be lowered using 
long-goto, lowering return would complicate the important tail-call optimization 
described on page 238. Lowering return is left as Exercise 23. 

Expressions are lowered using the rules in Table 3.4. Each rule is written as 
a relation of the form e ~ e’, pronounced “expression ¢ is lowered to expres- 
sion e’.” Rules in the first two groups use long-label and long-goto to imple- 
ment uScheme-+’s other control operators. Operators break, continue, throw, and 
return can be implemented using long-goto, for which suitable labels are intro- 
duced by the rules for while, try-catch, and lambda. 

The only rules that demand detailed explanation are those for try-catch and 
throw. The try-catch rule sets up a long-label expression whose result is a func- 
tion; that function takes one argument, a handler, and it returns the result of the 
try-catch. When try-catch terminates as the result of a throw, the function 
thrown is (lambda (h) (h x)), where x is the value thrown. This case therefore 


passes the value to the handler. When try-catch terminates as the result of its 
body terminating normally, the function produced is (lambda (h) x), where x is 
the value of the body. This case ignores the handler. 

Table 3.4 omits some important side conditions: break and continue expres- 
sions are lowered only inside a loop, and areturn expression is lowered only inside 
a function. Attempts to lower these operators outside of their expected contexts re- 
sult in an error message: 

215. (transcript 206a) += <1210b 
-> (lambda (x) (when x (break))) 
Lowering error: (break) appeared outside of any loop 


The lowering transformation reduces the number of rules needed to express 
the operational semantics: all the forms that can be lowered share a single rule, and 
none of those forms ever goes onto the evaluation stack. The operational semantics 
itself is the topic of the next section. 


3.5 A SEMANTICS OF CORE UWSCHEME+ 


The example abstract-machine transitions in Section 3.3 are justified by the opera- 
tional semantics of Core uScheme+. This semantics is an abstract-machine seman- 
tics, and it is defined by this transition relation between machine states: 


(e/v, p, 0,5) — (e'/v', p', 0", 5"). 


The notation e/v stands for the current item, which may be an expression e or a 
value v. 

An abstract-machine transition describes just one step in an evaluation, not 
the evaluation of an entire expression. Evaluating an entire expression usually re- 
quires multiple steps. A transition that may take multiple steps (zero or more) is 
written 

(e/v, p,0, 8) 3* (e’/v', p', 0’, 8’). 


The sequence of states thus passed through is often called a reduction sequence. 
Some special states and transitions are worth looking out for; spotting them 
will help you understand how the machine works. 


- Astate of the form (e, p, a, |]) is an initial state, meant to evaluate e. 


- A state of the form (v,p,0,[]) is a final state, reached after an evaluation 
completes. States of this form are the only acceptable final states; if the ma- 
chine is in any other state and it cannot make a transition, it is considered 
stuck. 


* In a transition of the form (e, p,0,S') — (e’, p,0, F :: S'), most likely e’ is 
the first subexpression of e€ to be evaluated, and Fis a frame formed from e 
by replacing e’ with a hole. 


- Ina transition of the form (v, p,0, F :: S) > (e, p,o, S'), e might be taken 
from F’, after examining v and F’. 


None of these special cases describes the evaluation of a control operator, which 
typically inspects multiple frames on the stack. 

The permissible transitions of the abstract machine are described by inference 
rules. These rules describe actions that differ from the actions described by big- 
step rules: In a big-step semantics, the action of evaluating a typical syntactic form 
is described by a single rule, and the evaluation of a conditional form, like if or 
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while, is typically described by two rules: one for a true condition and one for a 
false condition. In an abstract-machine semantics, the action of evaluating any 
syntactic form is usually spread out over at least two rules, and sometimes more. 
One rule says what to do with the form if it appears as the current item, and one 
says what to do if the form appears on the stack as a frame. And the rules for stack 
frames tend to be less uniform big-step rules: some forms never appear on the 
stack, and others may appear as frames with holes in different places, requiring 
multiple rules per form. 

Because the abstract-machine rules work so differently from the big-step rules, 
they are organized differently from the rules in Chapters 1 and 2. The rules fora 
single syntactic form still appear together, but based on how their evaluation affects 
the stack, the forms are organized into these groups: 


* Forms that are lowered, which don't change the stack 

* Other forms that don’t change the stack: LITERAL, VAR, and LAMBDA 

+ Forms that push just one frame onto the stack: SET and IF 

* Forms that evaluate subexpressions in sequence: APPLY, LET, and LETREC 

* Forms that inspect the stack and jump far away: LONG-LABEL, LONG-GOTO, 


and RETURN 


This grouping contrasts with all the other groupings in the book, which mostly 
show the same constructs in the same order (literal, variable, set, if, while, and 
so on). 

To help you compare the small-step reduction rules with big-step natural- 
deduction rules, rules of 4Scheme+ are accompanied by corresponding rules of 
pScheme. If you want to leap straight to the control operators, they are described 
in Section 3.5.5 on page 221. 


3.5.1 Forms that are eliminated by lowering 


If expression e can be lowered, then whenever e shows up as a current item to be 
evaluated, it is immediately replaced by its lowered form: 


ere! 


(e, 9,0, 5) oa (e’, p,0, 5) 


. (LOWER) 


The stack, environment, and store aren't consulted and don’t change. 

While the semantics specifies that an expression be lowered only when it is 
about to be evaluated, the lowering relation depends only on e’s syntactic form, 
not on any other property of the machine’s state. This independence enables an 
optimization: all lowerable expressions can be lowered preemptively, before eval- 
uation begins. In my implementation, no expression is lowered more than once, 
even if it is evaluated in a loop. 


3.5.2 Forms that don’t examine or change the stack 


A literal is evaluated without looking at the stack or the store. The small-step rule 
looks almost exactly like the big-step rule. 


; : . : (BIG-STEP-LITERAL) 
(LITERAL(v), p,0) |) (v,o) 


SMALL-STEP-LITERAL 
(LITERAL(0), 9,0, 5) > (op.0,5) 


Likewise, a variable is evaluated in one small step. The lookup is the same as 
in the big-step rule, and the stack S is unexamined and unchanged. 


x € domp p(x) € doma 
(vAR(2), 2,0) 4) (o(p(x)), c) 


(BIG-STEP-VAR) 


xé€domp p(x) €doma 
(vaR(x), p, 0,5) — (o(p(x)), p, 7,5) 
A LAMBDA expression is also evaluated in one step, as in the big-step semantics: 
the expression and the current environment are captured in a closure. Again, the 


small-step rule looks almost exactly like the big-step rule, and the stack is unexam- 
ined and unchanged. 


(SMALL-STEP-VAR) 


Bigssst Cp, all distinct 
(LAMBDA((@1,...,: Un),€), P, 7) |) ((LAMBDA((a1,...,¢ Un), €), P), 0c) 
(BIG-STEP-MKCLOSURE) 
Y1,..-+,%y all distinct 
(LAMBDA((1, oy stn); e); P,9%, S) me ((LAMBDA((x1, ees fn), e), p ), Ps 9, S) 


(SMALL-STEP-MKCLOSURE) 


3.5.3 Forms that push a single frame onto the stack 


If a form’s semantics require it to evaluate an expression, then do something, 
the form must push a frame on the stack. The simplest such form is assignment. 
The rule for SET(~, e) first pushes a frame that says, “I must assign to x,” then makes 
e the current item, where it will be evaluated. When e’s evaluation is complete, the 
SET frame is popped and is used to update x. The push-evaluate-pop sequence can 
be derived by analyzing the big-step rule: 


xé€domp p(«)=¢ (e, p,o) | (vu, a") 
(SET(x,e), p, 0) 4} (v,a/{£ 4 v}) 


(BIG-STEP-ASSIGN) 


An evaluation judgment (c,p,7) |) (v,c’) above the line is always implemented 
by a small step that makes e the current item and that pushes a frame that knows 
what to do with v. For SET, the frame is made by replacing e with a hole: 


x € domp 
(SET(x, e€), p,0,S) — (€, p, 0, SET(a, @) :: S)) 


(SMALL-STEP-ASSIGN) 


When e’s evaluation is complete, its value v will be the current item, and the frame 
SET(«,¢) will be on top of the stack. The abstract machine must pop the stack, 
update location ¢ = p(x), and produce v. 


p(x) =£ 
(v, p, 0, SET(x, @) :: S) > (v, p,o {£4 v}, S) 


(FINISH-ASSIGN) 


This rule is sound only because of a metatheoretic property of the semantics: 
if a machine makes a sequence of transitions from SMALL-STEP-ASSIGN to FINISH- 
ASSIGN, the p components of the two states are guaranteed to be the same. This 
property holds because any rule that changes the environment carefully saves the 
old environment on the stack. 

Another expression that pushes only one frame onto the stack is the IF expres- 
sion. Like an assignment, an IF is evaluated in two steps: first evaluate the condi- 
tion, then continue with one of the two branches. Because there are two ways to 
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continue, the old, big-step semantics has two rules: one for a true condition and 
one for a false condition. 


(e1,p,0) I (v1, 0") v, # BOOLV(#f) (€2, p,0") 4} (v2, 07") 


(IF(€1, €2,€3),—; oO) {| (V2, oui) 
(BIG-STEP-IFTRUE) 
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(e1,p,0) I) (vy, 0°’) V1 = BOOLV(#f (e3, p, 0’) 4) (v3, 0”) 
\ f f = \ } \ i f \ f 


(IF(€1, €2,€3), 2,0) |) (v3, 07") 

218 (BIG-STEP-IFFALSE) 
Look at both rules above the line. Each one begins with the same judgment, 
(e1,p,0) | (v1, 0"). Therefore, the small-step semantics can begin with the eval- 
uation of e;, and it can push a frame that waits for value v;. Again, that frame is 
made by replacing e; with a hole. The frame IF(e, e2, €3) saves both e2 and es on 
the stack, so no matter what v, is, the machine knows how to continue: 


(SMALL-STEP-IF) 


(IF(€1, €2, €3), P, 0, S) => (€1, Pp; oO; IF(@, €2, €3) u S) 


When IF(e, €9, e3) is on the stack and v is the current item, the machine continues 
by evaluating either e2 or e3—whichever would be dictated by the big-step rules: 


vu # BOOLV(#f) 


SMALL-STEP-IF-TRUE 
(v, p, 0, 1F(@, €2, €3) :: S) — (€2, p,0, 8) 


v = BOOLV(#f) 
(v, p, oO; IF(@, €2, €3) u S) => (€3, Ps 0; S) 


. (SMALL-STEP-IF-FALSE) 


3.5.4 Forms that evaluate expressions in sequence 


The forms that evaluate sequences of expressions (APPLY, LET, and LETREC) use 
the same idea as SET and IF—push a frame where a hole marks what the machine 
is waiting for—but because values in the sequence are delivered one at a time, the 
rules are more complicated. Each of these forms uses at least three kinds of rule: 


* Every form has a rule for when the form is encountered as the current item. 
That rule turns the form into a frame by putting a hole in the first position. 


* Every form has a rule for a hole in the middle of the sequence. The rule fills 
the hole with a value and moves the hole to the next position in sequence. 


* Every form has a rule fora hole in the last position in the sequence. That rule 
captures the entire sequence and continues. 


In addition, the APPLY form has a special rule for a hole in the first position, because 
that’s the function position, not an argument position, and the function is treated 
specially. 


Function application 
Function application has a lot going on. Here’s the big-step rule: 


li,..., ¢,, ¢ domo (and all distinct) 
(e,p,0) |) ((LAMBDA((x1,...,: Ln), Ce); Pc), Fo) 
(€1, P, 00) 4 (v1, 01) 


(Cn, P)On—1) 4b (Un, On) 
(Cc, Pe{@1 + b4,...5: tn t> lnbon{li U1,.-., bn 4 Un}) YL (vo, 0") 
(APPLY(€, €1,..., €n), P,7) (uv, a") 
(BIG-STEP-APPLYCLOSURE) 
Interpreted as “capture sequence and continue,” the rule works like this: 


+ Expressions €, €1,..., €n are evaluated in sequence. 


+ Once e evaluates to a closure uf and the arguments evaluate to v1,...,Un, 
vuy’s body is evaluated in a new environment built by extending p,. 


The small-step rules evaluate the sequence using an invariant: when e€, €1,...,€;_1 
have been evaluated and it’s time to start evaluating e;, the current item is e;, and 
the top of the stack holds the frame APPLY(v/,U1,...,Ui—1,®, €i+1,--+,€n). Here 
uf is the value of the function expression e (expected to be a closure or a primitive 
function), and v;,...,v;—1 are the results of evaluating the first  — 1 arguments. 
When evaluation of e; finishes, leaving v; as the current item, the hole is shifted 
one space to the right, leaving the frame APPLY(v ,V1,.-., Uj, , €i42,-+-,€n) ON 
top of the stack: 


(U, P, 0, APPLY (Uf, U1, ---, Vi-1, ©, C41, -+-5€n) 2S) 
(€i41, P; 7, APPLY(Uf, U1,..., Ui-1, U, @, C142, +--+, En) 2S) 
(SMALL-STEP-APPLY-NEXT-ARG) 
This rule corresponds to the transition that finishes the right-hand side of big-step 
judgment (¢;,?,7;-1) |) (v;,o;) (where v = v;) and starts the next judgment 
(€;41,2,0%) 4) (vi41,0%41). If the hole is in the first (function) position, a very 
similar rule applies: 


(v, P, 0, APPLY(@, €1,...,€n) 2: S) — (€1, p, 0, APPLY(U, @, €2,...,€n) 2: S) 
(SMALL-STEP-APPLY-FIRST-ARG) 
The APPLY(v, €1,..., €y,) frame is first pushed onto the stack when a function appli- 


cation appears as the current expression. The expression e in the function position 
becomes the new current item, i.e., the next thing to be evaluated. 


(APPLY(e, €1,---,€n), 0,0,5) — (e, p, 0, APPLY(@, €1,...,€n) :: S) 

(SMALL-STEP-APPLY) 

Finally, when all arguments have been evaluated, the top of the stack holds an 
APPLY frame in which the hole has the rightmost position; the state of the machine 
is (Un, P, 7, APPLY(Uf,U1,.-.,Un—1,¢@) 2: S'). What happens now? Looking back at 
the big-step rule, the last small-step rule has to implement the big-step judgment 
(€e, Pce{X1 +O b1,...,: Un > Lnbron{lr > v1,---,€n  Un}) I) (v, 0"). Mak- 
ing e, the current item is no problem, but the environment is another story. After 
expression €, is evaluated in the new environment, the machine has to revert the 
environment back to p. To save p while e, executes, the abstract machine pushes 
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it onto the stack in the form of a new frame ENV(p, CALL). The p is the saved envi- 
ronment, and the tag CALL says why the environment was saved. 


Uf = (LAMBDA((@1,...,%n),€c), Pe) 
l1,...,4n ¢ domo (and all distinct) 
(Un, PO, APPLY(Uf,U1,---,Un—1,¢) 1S) > 
Control operators (Cc, Pe{%1 + £1,.--,2n bn} on{lr FO U1,...,ln > Un}, ENV(p, CALL) :: S) 


(SMALL-STEP-APPLY-LAST-ARG) 


and a small-step Sai Me . 
After e,’s evaluation is finished, encountering ENV(p, CALL) on the stack restores p: 


semantics: uScheme+ 


220 (vu, p', 0, ENV(p, tag) :: S') + (v, p, 0,8) 
(SMALL-STEP-RESTORE-ENVIRONMENT) 
In informal English, the environment is pushed onto the stack just before a call, 
and when the call finishes, it is popped back off. This part of the semantics models 
real implementations of real languages: environment p holds machine registers 
and local variables, and ENV(p, CALL) is called a “stack frame” (or sometimes “ac- 
tivation record.”). 

Rule SMALL-STEP-APPLY-LAST-ARG applies only when vy is a closure. When vu 

is a primitive function, other rules apply, like this one: 


Vv] =NUMBER(n) vo =NUMBER(m) vu = NUMBER(n +m) 


V2, P, 7, APPLY PRIMITIVE(+ > U1,°® 25. = VU, Pp, 0,5) 


The LET expressions 


Sequences of expressions also occur in LET forms. In wScheme+, only LET and 
LETREC are part of the core; LETSTAR is lowered. Like APPLY, LET evaluates ex- 
pressions in sequence and builds a new environment in which to evaluate a body. 


li,..., £, ¢ doma (and all distinct) 
WT doe ay Vn all distinct 
(€1, P; 00) Ve (v1, 01) 


(En; P; On—1) a (Un; On) 
(e, p{a1 > b1,...,: tn t> ln}, onf{lr O U1,..., ln > Un}) db (wv, 0°) 
(LET((a1,€1,-- +5! En,€n),€), P, 0) 4 (v, 07) 


LET is implemented by these small-step rules: 


(U, P, 0, LET((1, U1, ---, Ui, ©, Vitd, Cid1;+-+)@n;€n),€) 2: S) 
(eit P, 9%, LET((21, 1, ey Bi, U, Ti41,0,---, Gis e) o S) 
(SMALL-STEP-NEXT-LET-EXP) 
L1,.-+-,%y all distinct 
) (SMALL-STEP-LET) 
(LET((21, €1, ne »Un; eas e), P; 0, S) =h 
(€1, 0, 0, LET((21, @, 2, €2,---,2n; En), €) 1: S) 
l1,...,4n ¢ domo (and all distinct) 
4 
(v, p, 0, LET((@1, V1,...,%n,@),e) 2S) > 
(e, p{t1  1,...,0n + Ln}, on{hi  U1,..., ln A Un}, ENV(p, NONCALL) :: S) 


(SMALL-STEP-LET-BODY) 


(v, p', 0, ENV(p, NONCALL) :: S) > (v, p,a, S) 
(SMALL-STEP-RESTORE-LET-ENVIRONMENT) 


The frame ENV(p, NONCALL) behaves the same way as ENV(p, CALL)—except, as 
shown on page 222, when viewed by the control operator return. 
The LETREC expression is quite similar to the LET expression, except it binds 


fresh locations into the environment before evaluating expressions €1,...,€n.- 
Chi, 28%s £, ¢ dom (and all distinct) 
Ds oe 54 Ly all distinct 
e; has the form LAMBDA(---), 1 <i<n 
p= pit h,...,: Ln, > Ly} 
do = off, + unspecified, ..., (, +» unspecified } 


(e1, p', 90) Al (v1, 01) 


(€n, P's; On-1) 1 (Un; On) 
(e, p',On{fi > U1,..-, Ln > Un}) I (vu, 0°) 
(LETREC((21,€1,---,;%n,€n),€), 2,0) Y (v, 0") 


(LETREC) 


LETREC is implemented by similar small-step rules, starting with this one: 


(U, P, 0, LETREC((21, U1,---, Ui, @, Vi41, Ci41,+-+;2n;y Cn), €) 2: S) 
(€j41, P) 0, LETREC((21,01,---,2j,U,2j41,@,---,€n),€) 1: 8) 
(SMALL-STEP-NEXT-LETREC-EXP) 
Again, the old environment is saved in the transition that introduces the new envi- 
ronment p’. In LETREC, that means saving when control enters the LETREC itself, 
not the body: 


%1,..-,%y all distinct 
e; has the form LAMBDA(---), 1 <i<n 
f1,...,€n € domo (and all distinct) 


p' = p{x1 > &1,...,an Ln} 
do = o{f; + unspecified, ..., 2, + unspecified} 
d 
(LETREC((21,€1,---,;Un;€n),€), P, 0,5) 
(€1, p', 00, LETREC( (21, ©, %2, €2,---, Xn, €n), €) 11 ENV(p, NONCALL) :: S') 


(SMALL-STEP-LETREC) 
l; = p(aj),l1<i<n 


(U, P, 0, LETREC((21,U1,.--,%n,@),e) 2 S) 9 


(e, p, o{ 01 + U1,---,€n-1 9 Un—1, ln + Vv}, S) 
(SMALL-STEP-LETREC-BODY) 


3.5.5 Forms that inspect the stack: LONG-LABEL, LONG-GOTO, and RETURN 


Finally, the control operators! These operators can’t easily be described using big- 
step semantics. Each operator carries one expression, and each operator begins 
by pushing itself on the stack with a hole in place of its expression. The expression 
becomes the current item, and when it is reduced to a value, the fun begins: 


1. If LONG-LABEL(L, e) is on top of the stack, it doesn’t do anything—it’s there 
just to mark a destination for LONG-GOTO. The frame is popped and evalua- 
tion continues. 


2. If LONG-GoTO(L, e) is on top of the stack, it looks at the next older frame on 
the stack. If that frame is LONG-LABEL(L,e), then the LONG-GOTO has ar- 
rived at its destination. Both frames are popped. Otherwise, the next frame 
is discarded, and evaluation continues by inspecting the next older frame 
after that. 
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3. RETURN works like LONG-GOTO, except its destination is not a LONG-LABEL 
frame; it’s a frame of the form ENV(p, CALL). 


Discarding part of the stack is called unwinding. 

ALONG-LABEL expression pushes its label onto the stack and evaluates its body. 
It also saves the current environment just below the label, so that after a control 
transfer, the environment is properly restored. 


(LONG-LABEL(L, e), p,0,S) — (e, p, 0, LONG-LABEL(L, @) :: ENV(~, NONCALL) :: S) 
(LABEL) 
If control is never transferred, eventually the LONG-LABEL frame is found on top of 
the stack, where it is ignored. 


LABEL-UNUSED 
(v, P, 0, LONG-LABEL(L, e) :: S') + (v, p,0,S) ( ) 


The LONG-LABEL frame is actually used as a target for LONG-GOTO, which be- 
gins by evaluating its expression: 


. G 
(LONG-GOTO(L, e), p,0,.5') > (e, p, 7, LONG-GOTO(L, e) :: S) foe 


Once the expression is evaluated, the LONG-GOTO continues by looking for its 
matching label. 


(vu, P, 7, LONG-GOTO(L, e) :: LONG-LABEL(L, @) :: S) + (uv, p,0,S) 
(GOTO-TRANSFER) 
If the next older frame isn’t label L, LONG-GOTO unwinds it: 


F #LONG-LABEL(L, e) 
(v, Pp, 0, LONG-GOTO(L,e) :: F':: 5) > (vu, p,0, LONG-GOTO(L, e) :: Ss) 
(GOTO-UNWIND) 
A RETURN works like a LONG-GOTO, except instead of looking for a correspond- 
ing LONG-LABEL, it looks for a frame of the form ENV(p’, CALL). 


R 
(RETURN(e), p,0,.S) — (€, p,0, RETURN(e) :: S') (RETURN) 


RETURN-TRANSFER 
U, P; 0, RETURN(e) :: ENV(p’, CALL) :: S) > (v, p',0, 5 ( ) 
p p p 


F does not have the form ENV(p’, CALL) 
(v, P, 0, RETURN(e) :: F’:: S') — (v, p, 0, RETURN(e) :: S') 


(RETURN-UNWIND) 


3.5.6 Rules for evaluating definitions 


As in Chapter 2, the judgment form (d,p,c7) —> (p',o’) says that the result of 
evaluating definition din environment p with store o is a new environment p’ and 
a new store o’. This judgment is a big-step judgment, just as in Chapter 2. And as 
in Chapter 2, DEFINE is syntactic sugar for a VAL binding to a LAMBDA expression, 
and a top-level expression is syntactic sugar for a binding to the global variable it, 
so the rules for DEFINE and EXP are the same as in Chapter 2. But because the 
evaluation judgment for expressions is different, the rules for evaluating VAL bind- 
ings are also different: they use the small-step evaluation relation presented in this 
chapter. 


A VAL form is treated differently depending on whether its variable is already 
bound in the environment. 


x € dom p 
(e, p, 7) | (vu, 0") 
(vAL(x,e), 2,0) > (p,0/{p(x) + v}) 


(BIG-STEP-DEFINEOLDGLOBAL) 


x ¢domp (¢domoa 
(SET(x,e), p{a > C},0{0 +> unspecified}) |) (v, 0’) 
(vAL(a,e),p,0) > (p{a + bl}, 0°) 
(BIG-STEP-DEFINENEWGLOBAL) 


The small-step versions of these rules are nearly identical, except that above the 
line, the big-step judgment (e, p, 0) |) (v, a’) is replaced by the transitive closure of 
the small step evaluation relation: (e, p,0,[]) >* (v, p’,o’,[]). The final value v 
and store o’ are used below the line, and the final environment p’ is thrown away. 
(It is a metatheorem of this semantics that p’ is the same as p.) 


x € dom p 
(e, p, 9 []) >* (v, p, 0", []) 
(vaL(x,e),p,0) — (p,o'{p(x) > v}) 


(SMALL-STEP-DEFINEOLDGLOBAL) 


zx¢domp £¢domoa 
(SET(z,e), p{a +> l},0{£ 4 unspecified}, []) >* (v, p, 0’, []) 


(vAL(x,e),p,7) — (p{x + Ef}, 0°) 
(SMALL-STEP-DEFINENEWGLOBAL) 


3.6 THEINTERPRETER 


The evaluator for zScheme-+, which uses the stack described in the operational 
semantics, is presented below. The stack itself is a standard data structure, so its 
implementation is relegated to Appendix M, as are functions for debugging, mem- 
ory management, and parsing control operators. The rest of the interpreter, in- 
cluding the psScheme parser, initial basis, primitives, and so on, is shared with the 
pScheme interpreter described in Chapter 2. 

Of all the interpreters in this book, the sScheme-+ interpreter least resembles a 
real-life interpreter. The stack inspection for long-goto is good, and using a stack 
to help evaluate expressions is common, but using a stack to implement break and 
continue is bizarre; sensible implementors use a stack to manage control transfers 
between procedures, not within a single procedure. 


3.6.1 Interfaces and instrumentation 
The evaluation stack 


The evaluation stack is a sequence of frames, each of type Frame. 


223. (type definitions for uScheme+ 223)= (S358) 226b> 
typedef struct Stack *Stack; 
typedef struct Frame Frame; 


The representation of Frame is exposed. A frame is represented by its form, which 
is typically an expression with a hole in it. Andif the expression is a function appli- 
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cation, then the frame also stores its original syntax. That syntax is used in error 
messages when, e.g., a program tries to apply a value that is not a function. 


224a. (structure definitions for uScheme+ 224a)= (S358) 
struct Frame { 
struct Exp form; // mutated in place during evaluation 
Exp syntax; // when not NULL, kept pristine for error messages 
3; 


A Stack is a mutable datatype. A Stack is created by emptystack, and it is 
mutated by pushframe, popframe, and clearstack (which pops all the remaining 
frames). 
224b. (function prototypes for uScheme+ 224b) = (S358) 224c > 

Stack emptystack(void); 
Exp pushframe (struct Exp e, Stack s); 
void popframe (Stack s); 
void clearstack(Stack s); 
Function pushframe pushes a frame in which syntax is NULL. 

Function topframe returns a pointer to the frame on the top of a stack—the 
youngest, most recently pushed frame—or if the stack is empty, it returns NULL. 
A stack s can safely be mutated by writing through topframe(s). 
224c. (function prototypes for 4Scheme+ 224b) += (S358) <1224b 224d> 

Frame *topframe(Stack s); // NULL if empty 

A frame may hold a saved environment, and such frames are pushed by the 
special function pushenv_opt, which can optimize tail calls (Section 3.6.11). 
224d. (function prototypes for zScheme+ 224b) += (S358) <224c 225a> 

void pushenv_opt(Env env, SavedEnvTag tag, Stack s); // may optimize 


Finally, the maximum size of the stack, in a single evaluation, is tracked in 
global variable high_stack_mark. 
224e. (global variables for 4Scheme+ 224e)= (S358) 224f> 
extern int high_stack_mark; // maximum number of frames 
Except for pushenv_opt, which is described in Section 3.6.11 on page 238, 
the implementations of the stack functions are relegated to Appendix M. 


Instrumentation 


To help you understand what happens on the evaluation stack, the wScheme-+ in- 
terpreter is instrumented with three options. Each option is a zScheme-+ variable 
whose value can influence the behavior of the interpreter. 


* Option &optimize-tail-calls, ifsetto#f, prevents the interpreter from op- 
timizing tail calls. 


* Option &show-high-stack-mark, if set to a non-#f value, prints the maxi- 
mum size of the stack after each definition is evaluated. 


* Option &trace-stack, if set to a nonnegative number n, shows the abstract- 
machine state for n steps. If &trace-stack is negative, all steps are shown. 
To change &trace-stack from a number to a non-number is an unchecked 
run-time error. 


Options &optimize-tail-calls and &show-high-stack-mark are used to set two 
global variables inside the interpreter: 
224f. (global variables for zScheme+ 224e) += (S358) <1224e 


extern bool optimize_tail_calls; 
extern bool show_high_stack_mark; 


Option &trace-stack triggers calls to these functions: 
225a. (function prototypes for 4Scheme+ 224b) += (S358) <1224d 225b> 
void stack_trace_init(int *countp); // how many steps to show 
void stack_trace_current_expression(Exp e, Env rho, Stack s); 
void stack_trace_current_value (Value v, Env rho, Stack s); 


To determine the value of an option, the interpreter calls getoption. If the 
option is not set, getoption returns defaultval. 


225b. (function prototypes for Scheme+ 224b) += (S358) <225a 225c¢> §3.6 


Value getoption(Name name, Env env, Value defaultval); The interpreter 


The instrumentation functions are implemented in Appendix M. << 


Diagnostic code for Chapter 4 


The wScheme-+ interpreter is used not only in this chapter but also in Chapter 4, 
which focuses on garbage collection. To help debug the garbage collectors, the 
interpreter frequently calls the validate function; provided the argument v repre- 
sents a valid value, validate(v) returns v. 


225¢. (function prototypes for 4Scheme+ 224b) += (S358) <1225b 231b> 
Value validate(Value v); 


3.6.2 Abstract syntax 


Definitions look exactly as they do in wScheme. 


225d. (ast.t 225d) = 225e> 
Def* = VAL (Name name, Exp exp) 

| EXP (Exp) 

| DEFINE (Name name, Lambda lambda) 


= DEF (Def) 
| USE (Name) 

| TEST (UnitTest) 
UnitTest* = CHECK_EXPECT (Exp check, Exp expect) 
| CHECK_ASSERT (Exp) 

| CHECK_ERROR (Exp) 


Expressions are divided into four groups. The first group contains the forms 
that are found in jsScheme: 


225e. (ast.t 225d) += <1225d 225f> 

Exp* = LITERAL (Value) type Env 153a 
VAR (Name) type Exp A 
SET (Name name, Exp exp) type Frame 223 
IFX (Exp cond, Exp truex, Exp falsex) type Name 43a 
WHILEX (Exp cond, Exp body) ee Basie 
BEGIN (Explist) type Stack 223 
LETX (Letkeyword let, Namelist xs, Explist es, Exp body) type Value A 
LAMBDAX (Lambda) 
APPLY (Exp fn, Explist actuals) 


The second group contains the new forms, all of which relate to control: 


225f. (ast.t 225d) += <1225e 226ab 
BREAKX 
CONTINUEX 
RETURNX (Exp) 
THROW (Name label, Exp exp) 


TRY_CATCH (Exp body, Name label, Exp handler) 
LONG_LABEL (Name label, Exp body) 
LONG_GOTO (Name label, Exp exp) 


The third group contains two forms that are used only in frames: the saved- 
environment frame and the hole. 


226a. (ast.t 225d) += <1225f 226c> 
| ENV (Env contents, SavedEnvTag tag) 
| HOLE 
226b. (type definitions for Scheme+ 223) += (S358) 1223 226d> 
Control operators typedef enum £ CALL, NONCALL 3 SavedEnvTag; 


and a small-step 


‘ The last two forms mark lowered expressions. A LOWERED form is printed as 
semantics: juScheme-+ 


its before component, but evaluated as its after component. A LOOPBACK form 
flags an expression for the garbage collector in Chapter 4; the evaluator evaluates 
whatever is inside. 
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226¢. (ast.t 225d) += <1226a 
| LOWERED (Exp before, Exp after) 
| LOOPBACK (Exp) 


3.6.3 Lowering 


The lowering transformation defined in Table 3.4 (page 214) takes an additional 
“lowering context” parameter that is not shown in the table. That parameter tells 
the transformation whether an expression appears inside a loop, inside the body 
of a function, or both. Operators break, continue, and return are lowered only 
when they appear in an appropriate context. 


226d. (type definitions for uScheme+ 223) += (S358) <226b 
typedef enum { LOOPCONTEXT = 0x01, FUNCONTEXT = 0x02 3 LoweringContext; 


A lowering function is defined for every kind of syntactic form that can contain 
an expression: true definitions, tests, extended definitions, and so on. All these 
functions call lower, which lowers an expression. Calling lower (context, e) re- 
cursively lowers every subexpression of e. And if the form of e calls for it to be 
lowered, lower returns e’s LOWERED form; otherwise it returns e. The code is repet- 
itive, and it just implements the rules shown in Table 3.4, so only two cases are 
shown here. The rest are relegated to Appendix M. 


226e. (definition of private function lower 226e)= (S350g) 
static Exp lower(LoweringContext c, Exp e) £ 
switch (e->alt) £ 
case SET: 
e->set.exp = lower(c, e->set.exp); 
return e; 
case BREAKX: 
if (c & LOOPCONTEXT) 
return mkLowered(e, mkLongGoto(strtoname(":break"), 
mkLiteral(falsev))); 
else 
othererror("Lowering error: %e appeared outside of any loop", e); 
(other cases for lowering expression e $351f) 


3 


3.6.4 Structure and invariants of the evaluator 


As in Chapters 1 and 2, the main judgment of the operational semantics—the state 
transition (e/v, p,0,S) — (e'/v’, p',o’, S’)—is implemented by function eval. 
This function starts with an expression e and an empty stack S, and it repeats the 
transition until the current item is a value v and the stack is once again empty. Then 
it returns v. Function eval’s essential invariants are as follows: 


The environment p is always in env and the stack is always in evalstack. 
As part of the state transition, these variables are mutated in place to hold p’ 
and 5”, respectively. 


When the stack is not empty, the youngest frame (the “top”) is pointed to by 
local variable fr (for “frame’”). 


When the current item is an expression e, that expression is stored in argu- 
ment e, and the state transition begins at label exp. 


* When the current item is a value v, that value is stored in local variable v, 
and the state transition begins at label value. 


« Each state transition ends with goto exp or goto value. Before the goto, ei- 
ther e or v is set to the current item for the next state. Variables env and 
evalstack are also set. 


227a. (eval-stack.c 227a)= 238 > 
Value eval(Exp e, Env env) ¢ 
Value v; 
Frame *fr; 
(definition of static Exp hole, which always has a hole $357c) 
static Stack evalstack; 


(ensure that evalstack is initialized and empty $344b) 
(use the options in env to initialize the instrumentation $346e) 


exp: 
stack_trace_current_expression(e, env, evalstack); 
(take a step from state (e, p, 7, S) 228a) 
assert(0); 
value: 
stack_trace_current_value(v, env, evalstack); 
v = validate(v); 
(if evalstack is empty, return v; otherwise step from state (v, p,0, fr :: S) 227b) 
assert(0); 


3 


227b. (if evalstack is empty, return v; otherwise step from state (v, p,0, fr :: S) 227b)= — (227) 
fr = topframe(evalstack); 
if (fr == NULL) § 
(if show_high_stack_mark is set, show maximum stack size $346g) 
return v; 
3 else § 
(take a step from state (v, p,o, fr :: S) 228b) 
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type Env 153a 


type Exp A 
falsev $327b 
type Frame 223 
lower $350e 


mkLiteral A 
mkLongGoto A 
mkLowered A 
othererror S184a 
type Stack 223 
stack_trace_ 
current_ 
expression 225a 
stack_trace_ 
current_ 
value 225a 
strtoname  43b 
topframe 224c 
validate 225c 
type Value A 
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When the current item is an expression e, 13 of the 22 expression forms in 


LScheme-+ are legitimate. 
228a. (take a step from state (e, p,o, S') 228a)= (227a) 


Switch (e->alt) £ 
case LITERAL: (starte->literal and step to the next state 229c) 
case VAR: (start e->var and step to the next state 229d) 
case SET: (start e->set and step to the next state 230a) 
case IFX: (start e->ifx and step to the next state 230c) 
case LETX: 

if ((e->letx contains no bindings 234b)) £ 

(continue by evaluating the body of the let or letrec 234c) 


3 else § 
Switch (e->letx.let) £¢ 
case LET: (start LET e->letx and step to the next state 234d) 


case LETSTAR: goto want_lowered; 
case LETREC: (start LETREC e->letx and step to the next state 235a) 
default: assert(0); 


3 
case LAMBDAX: (start e->lambdax and step to the next state 229e) 
case APPLY: (start e->apply and step to the next state 232c) 
case RETURNX: (start e->returnx and step to the next state 237c) 
case LONG_LABEL: (start e->long_label and step to the next state 236d) 
case LONG_GOTO: (start e->long_goto and step to the next state 237a) 
case LOWERED: (replace e with its lowered form and continue in this state 229a) 
case LOOPBACK: = (look inside LOOPBACK and continue in this state 229b) 
case WHILEX: case BEGIN: case BREAKX: case CONTINUEX: 
case THROW: case TRY_CATCH: 
want_lowered: runerror("internal error: expression %e not lowered", e); 
(expression-evaluation cases for forms that appear only as frames $357a) 


3 


An empty LETX form has no place for a hole, so that case is handled separately. 


When the current item is a value v, 9 of the 22 expression forms in uScheme+ 


may legitimately appear as the youngest (top) frame on the stack, fr. 
228b. (take a step from state (v, p,o, fr :: S) 228b)= (227b) 


switch (fr->form.alt) £¢ 
case SET: (fill hole in fr->form.set and step to the next state 230b) 
case IFX: (fill hole in fr->form.ifx and step to the next state 231a) 
case APPLY: (fill hole in fr->form.apply and step to the next state 233a) 
case LETX: 
switch (fr->form.letx.let) { 
case LET: (continue with let frame fr->form.letx 235b) 
case LETSTAR: goto want_lowered; 
case LETREC: (continue with letrec frame fr->form.letx 236a) 


default: assert(0); 
3 
case ENV: (restore env from fr->form.env, pop the stack, and step 236c) 
case RETURNX: (return v from the current function (left as exercise)) 


case LONG_GOTO: (unwind v to the nearest matching long-label 237b) 
case LONG_LABEL: (pop the stack and step to the next state 236e) 
(cases for forms that never appear as frames $357b) 


3 


The actions in each state are implemented below, starting with the simplest forms— 
the ones that don’t look at the stack. 


3.6.5 Interpreting forms that don’t change the stack 


To evalute an expression that has been lowered, replace it with its lowered form. 
Don't change the stack. 


ewe’ L 
OWER 
(e, p,0,5) — (e', p,a,S) 
229a. (replace e with its lowered form and continue in this state 229a)= (228a) 
e = e->lowered.after; §3.6 


goto exp; The interpreter 


To evaluate an expression tagged with LOOPBACK, replace the tagged form with 


the untagged form. Don’t change the stack. (The LOOPBACK tag is used only by the oP 
garbage collector in Chapter 4.) 
229b. (look inside LOOPBACK and continue in this state 229b)= (228a) 
e = e->loopback; 
goto exp; 
To evaluate a literal expression, take v out of the expression and make it the 
current item. Don’t change the stack. 
SMALL-STEP-LITERAL 
(Lirerat(v),p,0,5) > (v.p,0,5) : 
The machine must step to a state of the form (v, p, 0, S). Environment p and store 
o are unchanged, so the machine needs only to update v and to go to value. 
229¢. (start e->literal and step to the next state 229c)= (228a) 
v = e->literal; 
goto value; 
To evaluate a variable, look up its value and make that the current item. Don’t 
change the stack. 
x € dom x) € doma 
S px) (SMALL-STEP-VAR) 
(vaR(x), p,o,5) — (o(p(x)), p,9,S) 
229d. (start e->var and step to the next state 229d)= (228a) 
if (find(e->var, env) == NULL) 
runerror("variable %n not found", e->var); 
v = *find(e->var, env); 
goto value; 
To evaluate a LAMBDA, allocate a closure and make it the current item. Don’t 
change the stack. 
env 227a 
£1,..-, 2p all distinct tu 153b 
fr 227a 
(LAMBDA((21,.--,@n),€), P, 0,5) > ((LAMBDA((%1,.--,2%n),€),p), p,0,9) mkClosure A 
(SMALL-STEP-MKCLOSURE) punerror 47a 
Formal parameters 71,...,2,, are confirmed to be distinct when e is parsed. 
229e. (start e->lambdax and step to the next state 229e)= (228a) 


v = mkClosure(e->lambdax, env); 
goto value; 


3.6.6 Memory management for evaluation stacks 


Unlike the rules above, most small-step rules show transition from one stack to a 
different stack. The implementation keeps just one stack, which it updates in place. 
Because the stack contains frames, and a frame can be formed from an expression 


Control operators 
and a small-step 
semantics: juScheme-+ 


230 


in the program, frames need to be updated in a way that does not overwrite the 
syntax of the program. And frames’ memory needs to be allocated, preferably ina 
way that is more efficient than calling malloc before every push. 

Both needs are met by the Stack abstraction, which allocates memory for a 
large block of frames at once. A frame is represented as described by struct Frame 
in chunk 224a. Its form field is not a pointer; it is a struct Exp whose memory is 
part of the Frame. And pushframe (chunk 224b) pushes a struct Exp, not a pointer 
to one. So for example, to push a frame like IF(e, €2, e3), the interpreter builds the 
new frame using mkIfStruct, not mkIf: 


pushframe(mkIfStruct(hole, e2, e3), evalstack). 


Neither mkIfStruct nor pushframe allocates; this code builds a frame in memory 
that is owned by evalstack. So any field of any frame can be overwritten without 
affecting the expression from which that frame was built. This technique is all that 
is needed to implement SET and IF. 


3.6.7 Interpreting forms that push a single frame 
To evaluate SET, push a frame on the stack, then evaluate the right-hand side. 


x € domp 


SMALL-STEP-ASSIGN 
Ger(e,e), 0,5) > eposerce)es) | 


To implement the transition, the machine pushes the frame SET(x,e), updates e, 
and goes to exp. Environment and store are unchanged. 
230a. (start e->set and step to the next state 230a)= (228a) 
if (find(e->set.name, env) == NULL) 
runerror("set unbound variable %n", e->set.name); 
pushframe(mkSetStruct(e->set.name, hole), evalstack); 
e = e->set.exp; 
goto exp; 
The SET is completed by the FINISH-ASSIGN rule. When the youngest frame on the 
stack is a SET(x, @) frame, the machine completes the SET by assigning v to x, then 
pops the frame. 


p(x) = 


F -A 
(v, p,0,88T(@, #) 5) > (v,p,a{0> 0}, 8) sate 


230b. (fill hole in fr->form.set and step to the next state 230b)= (228b) 
assert(fr->form.set.exp->alt == HOLE); 
assert(find(fr->form.set.name, env) != NULL); 
*find(fr->form.set.name, env) = validate(v); 
popframe(evalstack); 
goto value; 


Because pushframe does not allocate, popframe need not deallocate. 
IF is implemented just like SET: to evaluate IF(€,,€2,e3), push the frame 
IF(@, €2, e3), then evaluate the condition e}. 


(SMALL-STEP-IF) 


(IF(€1, €2,€3),P,0,5) — (1, p, 0, IF(©, €2, €3) :: S) 


230c. (start e->ifx and step to the next state 230c)= (228) 
pushframe(mkIfxStruct(hole, e->ifx.truex, e->ifx.falsex), evalstack); 
e = e->ifx.cond; 
goto exp; 


When the youngest frame on the stack is an IF(e, €2, e3) frame, the machine con- 
tinues with e2 or e3, as determined by v. 
v # BOOLV(#f) 
(v, P,9, IF(@, €2; €3) S) => (e2, P,9, S) 


(SMALL-STEP-IF-TRUE) 


U = BOOLV(#f) 
(v, Ps, IF(@, €2, €3) S) re. (e3, P,9%, S) 
231a. (fill hole in fr->form.ifx and step to the next state 231a)= (228b) 


assert(fr->form.ifx.cond->alt == HOLE); 
e = istrue(v) ? fr->form.ifx.truex : fr->form.ifx.falsex; 


(SMALL-STEP-IF-FALSE) 


popframe(evalstack); 
goto exp; 
Next up is function application, which calls for infrastructure that can update 
a list of expressions within a frame. 


3.6.8 Updating lists of expressions within frames 


APPLY and LET expressions evaluate expressions in sequence. Values are accumu- 
lated by repeating a transition like the one in the SMALL-STEP-APPLY-NEXT-ARG 
rule on page 219, which takes a frame like APPLY(vf,U1,...,Ui-1, ®, Ci t1,-- +, €n) 
to one like APPLY(vys,U1,...,Vi-1,U,®, €i42,---,€n). In the originating frame, 
the sequence v1,...,Uj-1,®, €i41,---,@€n can be represented as a value of type 
Explist, where expressions €;+41...€, come from the original syntax, and val- 
ues U1,...,U;_1 are represented as LITERAL expressions. The transition is made 
by function transition_explist, which overwrites the hole with v, writes a new 
hole one position to the right, and returns the expression that was overwritten by 
the new hole. That expression is stored in static memory, so subsequent calls to 
transition_explist overwrite previous results. 

231b. (function prototypes for zScheme+ 224b) += (S358) <1225c¢ 231¢> 

Exp transition_explist(Explist es, Value v); // pointer to static memory 

When the hole is in the rightmost position, transition_explist overwrites the 
hole with v and then returns NULL. 

What about initializing a frame by putting a hole in the first position? Function 
head_replaced_with_hole works much like transition_explist: it puts a holein 
the initial position and returns a pointer to the expression that was there. If the list 
is empty, so there is no initial position, it returns NULL. 
231c. (function prototypes for zScheme+ 224b) += (S358) <1231b 231d> 

Exp head_replaced_with_hole(Explist es); // shares memory 
// with transition_explist 

A function like transition_explist helpsimplement APPLY, LET, and LETREC, 
but it has to be used carefully: if an Explist is overwritten, it can't be the origi- 
nal Explist from the syntax—it has to be a copy. The copy should be made when 
the frame containing the Explist is first pushed. For example, when the inter- 
preter pushes a frame like APPLY(e,¢€1,...,€,), it copies the list of expressions 
using function copyEL: 


pushframe(mkApplyStruct(mkHole(), copyEL(e,,...,€,)), evalstack). 


Function copyEL copies a list of expressions, and when the interpreter is finished 
with the copy, freeEL recovers the memory. 
231d. (function prototypes for zScheme+ 224b) += (S358) <1231c 232a> 
Explist copyEL(Explist es); 
void freeEL(Explist es); 


The interpreter calls freeEL when popping a frame that contains a copied Explist. 
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evalstack 227a 
type Exp A 
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find 153b 
fr 227a 
hole $357c 
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mkIfxStruct A 
mkSetStruct A 
popframe 224b 
pushframe 224b 


runerror 47a 
validate 225c 
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When an Explist appears in an APPLY, LET, or LETREC frame, each element 
goes through three states: 


1. Initially it points to fresh memory that contains a copy of syntax from the 
original expression. 


2. Atsome point the syntax is copied into static memory and the element’s own 
memory is overwritten to contain a hole. 


3. Finally the element’s own memory is overwritten with the value that results 
from evaluating the original expression. 


Once every element has reached its final state, the Explist contains only literals, 
and it can be converted to a list of values: 
232a. (function prototypes for zScheme+ 224b) += (S358) <1231d 232b> 
Valuelist asLiterals(Explist es); 
Value asLiteral (Exp e); 
Function asLiteral implements the same conversion, but for a single Exp. And 
because function asLiterals has to allocate, I provide freeVL, which frees the 
memory allocated by asLiterals. 
232b. (function prototypes for juScheme+ 224b) += (S358) <1232a 
void freeVL(Valuelist vs); 


These tools enable us to interpret forms that evaluate expressions in sequence. 


3.6.9 Interpreting forms that evaluate expressions in sequence 
Function application 


To evaluate an application, push an APPLY frame in which the function is replaced 
with a hole, and start evaluating the function. 


(APPLY(€, €1,.--,€n),0,0,5) > (e, p, 0, APPLY(@, €1,...,€n) 2: S) 
(SMALL-STEP-APPLY) 
As explained in the previous section, the list of actuals in the frame must be a copy 
of the list in the syntax. 
232c. (start e->apply and step to the next state 232c)= (228a) 
pushframe(mkApplyStruct(mkHole(), copyEL(e->apply.actuals)), evalstack); 
topframe(evalstack)->syntax = e; 
e = e->apply.fn; 
goto exp; 
When the youngest frame on the stack is an APPLY frame, the next state transi- 
tion is dictated by one of these three rules: 


d 
(U, P, 0, APPLY(@,€1,...,€n) 2: S) — (€1, 9,0, APPLY(U, @, €2,...,€n) 2: S) 
(SMALL-STEP-APPLY-FIRST-ARG) 


(U, P, 0, APPLY (Uf, U1, -- +, Vi-1, ©, C541, +--+; €n) 2S) 


(€i41, P; 7, APPLY(Uf, U1,..., Vi-1, U, @, C142, --+,€n) 2S) 
(SMALL-STEP-APPLY-NEXT-ARG) 


Uf = (LAMBDA((@1,...,%n),€c), Pe) 
l1,...,£n € domo (and all distinct) 
(Un, PO, APPLY(Uf,U1,---,Un—1,¢) 1S) > 
(€e; Pce{X1 + b1,..-,8n ln}, on{lr > U1,...,ln Un}, ENV(p, CALL) :: S) 


(SMALL-STEP-APPLY-LAST-ARG) 


Which rule does the dictating depends how the hole appears: as the function, as an 
argument, or as the last argument. There is also a case not given in the semantics: 
the list of arguments might be empty. 
233a. (fill hole in fr->form.apply and step to the next state 233a)= (228b) 
if (fr->form.apply.fn->alt == HOLE) { // Small-Step-Apply-First-Arg 
*fr->form.apply.fn = mkLiteralStruct(v); 
e = head_replaced_with_hole(fr->form.apply.actuals); 


if (e) 
goto exp; // Smal1l-Step-Apply-First-Arg 
else 
goto apply_last_arg; // empty list of arguments 
3 else ¢ 
e = transition_explist(fr->form.apply.actuals, v); 
if (e) 
goto exp; // Small-Step-Apply-Next-Arg 
else goto 


apply_last_arg; // Small-Step-Apply-Last-Arg 


3 
apply_last_arg: // Small-Step-Apply-Last-Arg (or no arguments) 
(apply fr->form’s fn to its actuals; free memory; step to next state 233b) 
Once the overwritten fr->form.apply.actuals and fr->form.apply.fn are 
converted to values, their memory is freed. The frame is popped, and the func- 
tion is applied. 


233b. (apply fr->form’s fn to its actuals; free memory; step to next state 233b)= (233a) 
£ 


Value fn asLiteral (fr->form.apply.fn); 
Valuelist vs = asLiterals(fr->form.apply.actuals); 
free (fr->form.apply.fn); 
freeEL(fr->form.apply.actuals); 


popframe(evalstack); 


switch (fn.alt) £ 
case PRIMITIVE: 
(apply fn. primitive to vs and step to the next state 233c) 
case CLOSURE: 
(save env; bind vs to fn.closure’s formals; step to evaluation of fn’s body 234a) 
default: 
runerror("%e evaluates to non-function %v in %e", 
fr->syntax—->apply.fn, fn, fr->syntax); 


3 
A primitive is applied in the standard way. 


233c. (apply fn. primitive to vs and step to the next state 233c)= (233b) 
v = fn.primitive.function(fr->syntax, fn.primitive.tag, vs); 
freeVL(vs); 
goto value; 


A closure is also applied in the standard way, according to this rule: 


Uf = (LAMBDA((@1,...,2n),€c), Pe) 
£1,...,4n € domo (and all distinct) 
(Un; P, 0, APPLY (Uf, U1,---,;Un—1,@) 1S) > 
(€e; Pe{X1 +> C1,..-,8n Enh, on{hi > U1,..., ln Un}, ENV(p, CALL) :: S) 


(SMALL-STEP-APPLY-LAST-ARG) 
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copyEL 231d 
evalstack 227a 
type Exp A 
type Explist S309b 
TP 227a 
freeEL 231d 
head_replaced_ 
with_hole 231c 

mkApplyStruct 

A 
mkHole A 
mkLiteralStruct 

A 
popframe 224b 
pushframe 224b 


runerror 47a 
topframe 224c 
transition_ 
explist 231b 
type Value <A 
type Valuelist 
$309c 


Before the body of the closure is evaluated, the environment is saved on the stack. 


234a. (save env; bind vs to fn.closure’s formals; step to evaluation of fn’s body 234a)= (233b) 


t 
Namelist xs = fn.closure.lambda. formals; 
checkargc(e, lengthNL(xs), lengthVL(vs)); 
pushenv_opt(env, CALL, evalstack); 
Control operators env = bindalloclist(xs, vs, fn.closure.env); 
and a small-step e = fn.closure.lambda.body; 
semantics: uScheme+ freeVL(vs); 
goto exp; 
234 z 


Interpreting LET and LETREC 


To evaluate a LET or LETREC that has no bindings, evaluate its body in environ- 
ment p. 
(EMPTY-LET) 


(LET((),€), 9,0) ¥ (e, p, 0) 


234b. (e->letx contains no bindings 234b) = (228a) 
e->letx.xs == NULL && e->letx.es == NULL 


234c. (continue by evaluating the body of the let or letrec 234c)= (228a) 
e = e->letx.body; 
goto exp; 


To evaluate a nonempty LET expression, push a frame in which the first right- 
hand side e; is replaced by a hole, and start evaluating e,. 


Y1,...,2y all distinct Gii-srepien 
(LET((a1,€1,---,;%n,€n),€),P, 0,5) 
(€1, 0, 0, LET((21, ©, ©2, €2,---,2n;€n), €) 1: S) 


The frame is built using a copy of e->letx.es, and the hole is inserted into the copy 
by calling head_replaced_with_hole. 
234d. (start LET e->letx and step to the next state 234d)= (228a) 

pushframe(mkLetxStruct(e->letx.let, e->letx.xs, 

copyEL(e->letx.es), e->letx.body), 
evalstack); 

fr = topframe(evalstack); 

e = head_replaced_with_hole(fr->form.letx.es); 

assert(e); 

goto exp; 


LETREC is almost like LET: 


%1,...,2y all distinct 
e; has the form LAMBDA(---), 1 <i<n 
£1,...,€n € domo (and all distinct) 


p' = p{a1 > 1,...,¢n > ln} 
do = o{f; + unspecified, ..., 2, + unspecified} 
(LETREC((21,€1,---,%n,€n),€), P,0,5) 
(€1, p', 00, LETREC((21, @, 12, €2,.-., Ln, €n), €) 1: ENV(p, NONCALL) :: S) 


(SMALL-STEP-LETREC) 
To evaluate LETREC, save the environment on the stack, then extend it with fresh 
locations that are given unspecified values. Then, as for LET, push a LETREC frame, 


replace the first right-hand side with a hole, and start evaluating it. As in Chapter 2, 
the right-hand sides are confirmed to be LAMBDAs at parse time. 


235a. (start LETREC e->letx and step to the next state 235a)= (228a) 
pushenv_opt(env, NONCALL, evalstack); 
(bind every name in e->letx.xs to an unspecified value in env $357d) 
pushframe(mkLetxStruct(e->letx.let, e->letx.xs, 
copyEL(e->letx.es), e->letx.body), 
evalstack); 
bi topframe(evalstack); 
e = head_replaced_with_hole(fr->form.letx.es); 
assert(e); 
goto exp; 


A LET expression in progress is governed by these rules: 


d 


(v, p, 0; LET((21, U1, ve UE, O, Vi41, Gi41,--- pPrvlnyse) u S) a 


(€j41, P, 0, LET((@1, U1,---,Ui,U, Li41,@,--+,€n),e) 2: S) 
(SMALL-STEP-NEXT-LET-EXP) 

f1,...,4n ¢ domo (and all distinct) 

,In,@),e) 2S) > 


(v, 0,0, LET((1, U1,--- 
(e, p{t@1  b1,...,0n + Ln}, on{hi  U1,..., ln Un}, ENV(p, NONCALL) :: S) 
(SMALL-STEP-LET-BODY) 
Both rules are implemented by function transition_explist, which puts v in 
the hole and moves the hole. But if the hole is in last position, implementing the 
SMALL-STEP-LET-BODyY rule is tricky. Before the frame LET((11, V1,..-,2n,®),€) 
is popped, names %1,...,£» are used to update the environment p, but after the 
LET frame is popped, the original p needs to be saved on the stack. The steps are 
shown by numbered comments in the code. 
235b. (continue with let frame fr->form.letx 235b)= (228b) 
e = transition_explist(fr->form.letx.es, v); 


if (e) { // Small-Step-Next-Let-Exp 
goto exp; 
3 else § // Small-Step-Let-Body 
Namelist xs = fr->form.letx.xs; // 1. Remember x's and v's 
Explist es = fr->form.letx.es; 
Valuelist vs = asLiterals(es); 
e = fr->form.letx.body; // 2. Update e 
popframe(evalstack); // 3. Pop the LET frame 
pushenv_opt(env, NONCALL, evalstack); // 4. Push env 
env = bindalloclist(xs, vs, env); // 5. Make new env 
freeEL(es); // 6. Recover memory 
freeVL(vs); 
goto exp; // 7. Step to next state 
3 


The expressions in a LETREC are already evaluated in an extended environ- 
ment, so when the last expression is evaluated, the only step needed before evalu- 
ating the body is to update the store. 


(U, P, 0, LETREC((X1,U1,---, Ui, @, i411, Ci41,---;€n;n),€) 2S) 
(€j41, P) 0, LETREC((21,U1,---,%i,U, 2i41,©,---;€n),€) 2: S) 
(SMALL-STEP-NEXT-LETREC-EXP) 
(u, P, 0, LETREC((21,01,---,2n,@),e) 2S) 9 
(e, p, 7{ 0, 4 U1,.--,ln—-1 > Un—1; ln 2 Vv}, S) 
(SMALL-STEP-LETREC-BODY) 
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asLiterals 232a 


bindalloclist 
153c 
checkarge 47c 
copyEL 231d 
env 227a 


evalstack 227a 
type Explist S309b 


fn 233b 
fr 227a 
freeEL 231d 
freeVL 232b 


head_replaced_ 
with_hole 231c 
lengthNL A 
lengthVL A 
mkLetxStruct 
A 
type Namelist 
43a 
popframe 224b 
pushenv_opt 224d 
pushframe  224b 
topframe 224c 
transition_ 
explist 231b 
type Valuelist 
$309c 


236a. (continue with letrec frame fr->form.letx 236a)= (228b) 
e = transition_explist(fr->form.letx.es, v); 
if (e) {§ // Small-Step-Next-Letrec-Exp 
goto exp; 
3 else § // Small-Step-Letrec-Body 
(put values in fr->form.letx.es in locations bound to fr->form.letx.xs 236b) ; 
freeEL(fr->form.letx.es); 


Control operators e = fr->form.letx.body; 
and a small-step popframe(evalstack); 
semantics: j4Scheme-+ goto exp; 
3 
236 ‘ F : 
236b. (put values in fr->form.1letx.es in locations bound to fr->form.letx.xs 236b)= (236a) 
£ 
Namelist xs = fr->form.letx.xs; 
Explist es = fr->form.letx.es; 
while (es || xs) £ 
assert(es && xs); 
assert(find(xs->hd, env)); 
*find(xs->hd, env) = asLiteral(es->hd); 
es = es->tl; 
XS = xs->tl; 
3 
3 


The LET and APPLY forms both save environments on the stack. When the 
youngest frame on the stack is an ENV frame, the saved environment is restored 
by assigning it to env. In this context, the tag is ignored. 


(v, p', 0, ENV(p, tag) :: S) — (v, p,0,S) 
(SMALL-STEP-RESTORE-ENVIRONMENT) 
236c. (restore env from fr->form.env, pop the stack, and step 236c)= (228b) 
env = fr->form.env.contents; 
popframe(evalstack); 
goto value; 


3.6.10 Interpreting control operators 


Only the long-label, long-goto, and return forms are interpreted in eval. The 
other control operators are implemented by lowering. 

To evaluate a label, save the current environment and the label on the stack, 
then evaluate the body. 


(LONG-LABEL(L, e), p,0,S) — (e€, p,0, LONG-LABEL(L, @) :: ENV(p, NONCALL) :: S) 
(LABEL) 
236d. (start e->long_label and step to the next state 236d)= (228) 
pushenv_opt(env, NONCALL, evalstack); 
pushframe(mkLongLabelStruct(e->long_label.label, hole), evalstack); 
e = e->long_label.body; 
goto exp; 


When the youngest frame on the stack is a LONG-LABEL frame, it is simply popped. 


LABEL-UNUSED 
(v, Pp, 0, LONG-LABEL(L, e) :: S) — (uv, p,0, S) ( ) 
236e. (pop the stack and step to the next state 236e)= (228b) 


popframe(evalstack); 
goto value; 


The label’s purpose is to serve as a target for LONG-GOTO. To evaluate a LONG- 
GOTO, push a LONG-GOTO frame, then evaluate the body. (For an alternative se- 
mantics, see Exercise 12.) 


(GOTO) 
(LONG-GOTO(L, e€), p,0, 5) > (e, p,7, LONG-GOTO(L, e) :: S) 
237A. (start e->long_goto and step to the next state 237a)= (228a) 
pushframe(mkLongGotoStruct(e->long_goto.label, hole), evalstack); 
e = e->long_goto.exp; 
goto exp; 


Once the body of the LONG-GOTO has been evaluated and the youngest frame on 
the stack is LONG-GOTO(L, e), the machine starts looking for a target label. It uses 
these two rules: 


F #LONG-LABEL(L, @) 


(v, p, 0, LONG-GOTO(L, e) :: F:: 5) — (v, p,0, LONG-GOTO(L, e) :: S)” 
(GOTO-UNWIND) 


(v, Pp, 7, LONG-GOTO(L, @) :: LONG-LABEL(L, e) :: S) — (uv, p, 0, S) 
(GOTO-TRANSFER) 
To implement the rules, the interpreter pops the stack, setting fr to the next 
youngest frame. If fr points to the label L, it too is popped, and the transfer is com- 
plete. Otherwise, *fr is overwritten with LONG-GoTO(L, e), effectively unwinding 
one frame from the stack, and evaluation continues. 


237b. (unwind v to the nearest matching long-label 237b)= (228b) 
~ Name label = fr->form.long_goto.label; 

popframe(evalstack); // remove the LONG_GOTO frame 
fr = topframe(evalstack); // fr now points to the next youngest frame 
if (fr == NULL) { 

runerror("long-goto %n with no active long-label for %n", 

label, label); 
3 else if (fr->form.alt == LONG_LABEL && 
fr->form.long_label.label == label) ¢ 

popframe(evalstack); 

goto value; 
3 else { 

fr->form = mkLongGotoStruct(label, hole); 

goto value; 


3 


Like a long-goto, a return pushes a frame, then evaluates its expression. 


(RETURN) 
(RETURN(e), p,0,S) — (€, ,0, RETURN(e) :: S) 
237¢. (start e->returnx and step to the next state 237c)= (228a) 

pushframe(mkReturnxStruct(hole), evalstack); 

e = e->returnx; 

goto exp; 


Once a return’s expression has been evaluated and the youngest frame on the stack 
is RETURN(e), the machine unwinds the stack until it finds an ENV frame with a 
CALL tag. The implementation is left for you, as Exercise 20. 


237d. (return v from the current function [prototype] 237d) = 
runerror("Implementation of (return e) is left as an exercise"); 
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asLiteral 232a 
env 227a 
evalstack 227a 
type Explist S309b 


find 153b 
TP 227a 
freeEL 231d 
hole $357c 
mkLongGotoStruct 
A 
mkLongLabelStruct 
A 
mkReturnxStruct 
A 


type Name 43a 
type Namelist 
43a 
popframe 224b 
pushenv_opt 224d 
pushframe  224b 


runerror 47a 
topframe 224c 
transition_ 


explist 231b 
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3.6.11 Implementing proper tail calls 


Environment frames are tagged so that tail calls can be optimized (Section 2.14.2, 
page 170). The optimization ensures that a function called in a tail context reuses 
the stack space of its caller. Tail contexts are determined by the syntactic structure 
of a function’s body, but an expression evaluated in a tail context is evaluated ina 
dynamic context—that is, a run-time machine state—in which the top of the stack 
holds one or more ENV frames, at least one of which has a CALL tag (Exercise 16). 
Using the semantics in this chapter, tail-call optimization is easy to express; 
tail calls are optimized if the evaluation stack never holds consecutive ENV frames. 
For example, any evaluation stack of the form ENV(2, CALL) :: ENV(1, CALL) :: S 
should be optimized to ENV(p1, CALL) :: S'. (The environments p; and p2 are num- 
bered in the order in which they are pushed on the stack.) So if the youngest frame 
on the stack is an ENV(p1, CALL), the interpreter does not push ENV(2, CALL). 
This optimization is justified by two metatheoretic claims: 


U, P, 0, ENV(p2, CALL) :: ENV(p1, CALL) :: S') +* (v’, p', 0", 
p p p p 
if and only if 
(v, P, 0, ENV(p1, CALL) :: S') >* (v’, p’, 0’, []), 
and 
€, P, 0, ENV(p2, CALL) :: ENV((1, CALL) :: S) >* (vu o 
,P, 7, ENV(p2, Pi, S) * (v', p', 0°, 


if and only if 


(e, P, 0, ENV(p1, CALL) :: S) * (v’, p', 0’, []). 


These claims can be proved in Exercise 13, and the ideas of the proof are worth 
examining here. First, when the current item is a v, the first claim is easily and 
directly verified by appealing to the operational semantics. When the current item 
is an e, there are three possibilities: 


- If e evaluates to v, then for any stack S’, (e, p,0,S’) >* (v, p’, a’, S’), and 
from there the v cases apply. 


* If the evaluation of e gets stuck or keeps transitioning forever, it doesn’t mat- 
ter what’s on the stack. 


* If e tries to unwind the stack, a long-goto unwinds two call frames as easily 
as one. A return behaves a little more differently in the two cases, but they 
wind up in the same state. 


In the examples above, every ENV frame has a CALL tag, but to get true, proper 
tail calls in all circumstances, stacks involving any mix of tags must also be opti- 
mized. Working out the semantics is Exercise 14; the code looks like this: 

238. (eval-stack.c 227a) += 1227a 
void pushenv_opt(Env env, SavedEnvTag tag, Stack s) { 
assert(s); 
Frame *f = optimize_tail_calls ? topframe(s) : NULL; 
if (f && f->form.alt == ENV) ¢ // don't push a new frame 
if (tag == CALL && f->form.env.tag == NONCALL) 
f->form.env.tag = CALL; 
3 else £§ 
pushframe(mkEnvStruct(env, tag), S$); 


3.7 STACKS, CONTROL, AND SEMANTICS AS THEY REALLY ARE 


3.7.1 Stacks in programming languages 


The evaluation stack used in wScheme-+’s semantics and interpreter is closely re- 
lated to stacks used in real languages. The key difference lies in the representation 
of intraprocedural control. In real languages, control information is stored in a 
sequence of instructions for a real or virtual machine, and control transfer is im- 
plemented by conditional or unconditional branch instructions. In wScheme+, 
by contrast, control information is stored on the evaluation stack, and control 
transfer is implemented by popping a frame off the stack. For example, a real 
if expression is implemented by testing a condition register and using its state to 
transfer control to a labeled instruction sequence for expression €2 or €3, using a 
conditional branch instruction. In zScheme-+, v acts like a condition register, but 
the destination of the control transfer (e2 or €3) is taken off the evaluation stack. 

Although real languages handle intraprocedural control in different ways from 
pScheme-+, real implementations do use stacks that look like special cases of our 
evaluation stack. For example, a language that supports recursive procedures uses 
a call stack. A call stack saves the locations and/or values of local variables, just like 
the ENV frames in our evaluation stack. A call stack also saves control information 
between procedures—at compile time, a procedure doesn’t know who its caller is, so 
that information can't be compiled in. Control information on a call stack usually 
takes the form of a return address, which points into the instruction sequence of a 
calling procedure. 

Real tail-call optimization works just like our model: when f calls g and g makes 
an optimized tail call to h, g doesn’t push a new frame on the call stack. Instead, 
g arranges for h to see f’s frame, and when h returns, it returns directly to f. 

Some real implementations use a stack to evaluate function applications and 
similar expressions. Such an implementation includes an operation like “evalu- 
ate e and push its value on the stack.” Using this operation, an application like 
(+ €1 €2) would be implemented by first pushing the value of e,, then pushing the 
value of €2, then adding the top two values on the stack. This technique is used 
in the Java Virtual Machine as well as in common microcontroller hardware. And 
in some languages, such stack-based computation is exposed directly to program- 
mers; my two favorites are PostScript and Forth. 


3.7.2 Control operators 


The control operators break, continue, and return, as depicted in this chapter, are 
provided by many languages. Sometimes break is extended so it can exit a nest of 
several loops. For example, in the POSIX shell language, break may take a numeric 
argument that says how many nested loops to exit; in Ada, a loop can be named with 
a label, and a break statement can use that label. 

Although break, continue, and return are often used in the same way as in 
pScheme-+, they are not implemented in the same way. Any compiler, and most 
interpreters, will use a static analysis—which means “looking at the code”—based on 
a proof system like the one you can create in Exercise 18. The static analysis keeps 
track of the possible evaluation contexts at every position in the source code, and 
it uses this information to lower break, continue, and return into simple, “short” 
goto instructions, instead of our “long” ones. Such instructions don’t inspect the 
stack at run time. 
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type Frame 223 
mkEnvStruct A 
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calls 224f 
pushframe  224b 
type SavedEnvTag 
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Forms like try-catch and throw are found in dozens of real languages, usually 
under the name exceptions. There are many refinements. 


+ A try-catch can be associated with “cleanup” code that executes once the 
body and/or the handler have finished, regardless of whether an exception 
is raised. Cleanup code is usually marked by a finally keyword, but not al- 
ways: Common Lisp provides a separate unwind-protect form (Exercise 21). 


* In JavaScript, try, catch, and throw work much as they do in psScheme+, 
except that the control operators are unlabeled, so throw always transfers 
control to the youngest active catch. 


+ In Java, exceptions are specified using Java’s class system, which somewhat 
resembles the class system of jsSmalltalk (Chapter 10). A Java exception 
is an object of the special class Throwable, or of a class that inherits from 
Throwable. A catch handler names one of these classes instead of a label, 
and it catches objects of the named class and of classes that inherit from it. 


* In Modula-3, exceptions are distinct from values, variables, and functions; 
new exceptions are defined by a special definition form. Each exception 
is named, and a throw (called RAISE in Modula-3) names the exception it 
throws. The exception’s definition also specifies the type of values that may 
be thrown, if any. A handler may name the exceptions it handles or may 
offer to handle all exceptions. 


Exceptions can interact with other control operators, and in Modula-3, the 
interaction is explained in an unusually elegant way: both break and return 
are lowered into throw/RAISE operators that use special exceptions, which 
no program can name. This explanation is consistent with the lowering 
transformation used in puScheme+. 


The implementation of long-goto used in this chapter, which involves in- 
specting the stack and unwinding it to reach a handler, models the widely used 
“Zero overhead” technique of implementing exceptions. The “zero overhead” tech- 
nique associates handlers and return addresses at compile time, so at run time, 
a try-catch can be entered without incurring any run-time cost. All the overhead 
is incurred by throw (modeled by long-goto), which visits every frame on the call 
stack and looks up each return address to see if it lies within the scope of a handler. 
A try-catch is therefore “free,” but throw may be moderately expensive. 

A popular alternative technique pays a small cost to enter a try-catch— 
typically just a few instructions, which push the handler’s address on a stack—but 
makes it possible to implement throw in constant time. This technique can be 
implemented efficiently if the handler stack shares memory with the call stack; 
the only additional datum needed is a pointer to the top of the handler stack, which 
may be kept in a global variable or a machine register. This technique is used in 
the functional language OCaml, for example. 


3.7.3 Small-step semantics 


Small-step semantics are widely used. One reason is they enable a powerful proof 
technique: if a property holds of every initial state, and if that property is preserved 
by every state transition permitted under the semantics, then that property holds 
of every reachable state. This proof technique is quite good at proving safety prop- 
erties, which say that good programs don’t do bad things. One example is memory 
safety; in a memory-safe program, the condition 2 € doma is always satisfied. Ex- 
amples of languages that are memory-safe include full Scheme and Standard ML. 


Examples of languages that are not memory-safe include C and C++. Unsafe access 
to memory can lead to bugs, blue-screen crashes, and security exploits. 
Small-step semantics are also widely used because they can easily be extended 
to talk about actions taken by programs, such as I/O and communication. For ex- 
ample, the state-transition arrow can be labeled. Labels can say things like this: 


¢ The transition causes the abstract machine to write a character to standard 
output. 


* The transition causes the abstract machine to send a message. 


¢ The transition causes the abstract machine to consume a character from 
standard input; the value of the character is bound to the name c. 


* The transition happens only when the abstract machine receives a message, 
and the contents of the message are bound to the name m. 


Small-step semantics come in many forms—not all state machines use seman- 
tic objects as part of their states. If the components of a state machine are purely 
syntactic, its semantics is a reduction semantics. In the most extreme form, the en- 
tire state is an expression or other syntactic term in some programming language; 
the language described by such a semantics is usually called a calculus. In a cal- 
culus, each transition rewrites one syntactic form into another syntactic form; 
such a transition is usually called a reduction. Calculi worth knowing about in- 
clude Church’s \-calculus, which models functional programming, and Milner’s 
m-calculus, which models mobility and communication (Rojas 2015; Milner 1999). 

Calculi often have nondeterministic semantics: a machine might have a choice 
about which state it can transition to. For example, Church's \-calculus has an 
important choice when a lambda abstraction is applied: the abstract machine can 
try to reduce the function’s argument or it can substitute the argument into the 
function's body. Church and Rosser proved that either choice can lead to the same 
final result: no matter what reduction the machine chooses, it can choose future 
reductions such that from any reachable state, there are sequences of reductions 
that eventually arrive at the same state. But the choice makes a big difference in 
the way implementations perform and behave: a machine that reduces the func- 
tion’s argument first corresponds to a strict or eager evaluation strategy, as in ML or 
Scheme, and a machine that substitutes into the function’s body first corresponds 
to a lazy evaluation strategy, as in Haskell. 

The semantics of Core uScheme- is intended to be deterministic. That is, in any 
given state, the next state is completely determined—unless the abstract machine 
is stuck or in a final state, it transitions to exactly one next state. A deterministic 
semantics determines an evaluation strategy, which, in a calculus, can be specified 
using an evaluation context. This is a data structure or a chunk of syntax that locates 
a currently evaluated expression in a larger syntactic context. For example, eval- 
uation contexts for Core uScheme-+ can be described by this (partial) grammar; 
a context is C’, a value is v, an expression is e, anda name is x or L: 


Ciu=e 

(set xC) 

(if C eg €3) 

(Ce1 +++ €n) 

(VUy +++ Uji-1 C e441 ++ En) 

(let ([@1 v1] +++ [@j—1 Vi-1] [ai CT] [aig €i41] +++ [%n €n]) €) 
(return C) 

(long-label LC) 

(long-goto LC) 


§3.7 
Stacks, control, 
and semantics as 
they really are 


241 


Control operators 
and a small-step 
semantics: juScheme-+ 


242 


The evaluation contexts specified by this grammar enforce not only an eager eval- 
uation strategy but also an evaluation order: in the evaluation context for function 
application, everything to the left of the hole is guaranteed to be a value; only things 
to the right of the hole can be expressions. The context for let is similar. The eval- 
uation contexts ensure that actual parameters and right-hand sides are evaluated 
from left to right. 

Evaluation contexts are closely related to evaluation stacks. And the grammar 
of contexts can be converted to a grammar of frames; simply replace each nested 
context with a hole: 


F ::= (set re) 

(if ee €3) 

(@€1 +++ €n) 

(UV1 +++ Vi-1 © Ei41 ++* En) 

(let ([%1 vi] +++ [@j—1 Vi-1] [Xi ©] [%i41 Ci41] °°: [¥n €n]) €) 
(return e) 

(long-label L e) 

(long-goto Le) 


Each stack of frames corresponds to a unique evaluation context, and vice versa. 
As described in Exercise 15, the correspondences can be implemented as a pair of 
functions. 


3.7.4 Continuations 


An evaluation context C’' (or equivalently, a stack S$) can represent a function: the 
function that takes one argument v, plugs v into the hole in C,, then evaluates the 
resulting expression. This is the same function that performs the computation you 
get when executing the abstract machine in the state (v, 9,0,S), where S is the 
stack that corresponds to C’. And in some languages, the stack or context in which 
an expression is evaluated can be captured as a function, which is called the ex- 
pression’s continuation. Such a language is said to provide first-class continuations; 
it enables code both to capture an evaluation context as a value and to use such a 
value as an evaluation context. 

The idea of continuations is the same as the one embodied by success and fail- 
ure continuations in Chapter 2; to make continuations first class, a language needs 
a mechanism that turns a point in the program into a continuation. The most fa- 
mous mechanism is probably call with current continuation, usually abbreviated 
call/cc, which is part of full Scheme. It works like this: 


* The language is extended with a new value form CONTINUATION(S). Like a 
closure (A((x), e), p |) or a PRIMITIVE value, a CONTINUATION(S) represents 
a function—in this case, a function of a single argument. 


* When a continuation CONTINUATION(,S’) is called, the stored context S’ re- 
places the current evaluation context. This operation is sometimes called en- 
tering the continuation. It is described by this rule: 


Uf = CONTINUATION(.S") 
(v1, P, 7, APPLY(vy,¢) :: S) > (v1, p,o, 5") 
(APPLY-UNDELIMITED-CONTINUATION) 
The “undelimited” part of the name is explained at the end of this section. 


* The current continuation is captured by a new primitive, call/cc. “Capture” 
means “make a copy of.” 


(v1, P, 0, APPLY(PRIMITIVE(call/cc),e) ::S) > 


(APPLY(v1, CONTINUATION(S)), p, 0, 5’) 
(CALL-WITH-CURRENT-CONTINUATION) 


As an example, suppose f is the function (lambda (k) (k 5)). Then the ex- 
pression (+ (call/cc f) 4) evaluates to 9. That’s because the continuation cap- 
tured by call/cc is roughly APPLY(PRIMITIVE(+), @, LITERAL(4)), and it behaves 
like the function (lambda (x) (+ x 4)). So (call/cc f) behaves like the expression 
(f (lambda (x) (+ x 4))), which evaluates to 9. 

In theory, call/cc is a magnificent operation because it can be used to im- 
plement a remarkable range of control operators: coroutines, backtracking, Icon- 
style generators, nondeterministic choice, setjmp/longjmp, and more. (Think of 
call/cc as setjmp enhanced with mutant superpowers.) As just one example, 
my personal favorite, call/cc can be used to implement concurrent processes 
with message passing (Haynes, Friedman, and Wand 1984; Ramsey 1990). Using 
call/cc appeals to theorists and other minimalists because call/cc is all you need; 
a ton of other language features and control operators can simply be lowered into 
call/cc. And call/cc can be fun to program with. But in practice, call/cc is not 
so great. It’s not widely implemented—copying an entire stack is expensive, and 
that expense can be avoided only if your implementation is really clever. More- 
over, many features that might be lowered into call/cc don't actually use its full 
power, which includes the power to enter a single continuation multiple times. 

And the implementation problems pale beside the modularity problems: A con- 
tinuation might look like a function, but it doesn’t behave like a function. In particu- 
lar, it doesn’t compose with other functions: The composition f og makes it look like 
f will be applied to whatever result g returns, but if g is a captured continuation, 
the application of f is part of the context S that is destroyed when g is applied. 

Continuations that are captured with call/cc are called undelimited. Acall/cc 
can grab an unbounded amount of context, and when the resulting continuation is 
entered, it can discard an unbounded amount of context. An interesting alterna- 
tive, which addresses some of the modularity problems, is a delimited continuation; 
for example, a delimited continuation might capture just a portion of the evaluation 
stack, up to a delimiter that works a bit like long-1abe1, and turn it into a function. 
Delimited continuations are mentioned below as possible further reading. 


3.8 SUMMARY 


Control operators can be awkward to handle with a big-step semantics. And big- 
step semantics cannot describe a computation that continues forever, like an op- 
erating system or a web server. These situations call for a small-step semantics, 
in which each step “reduces” a term or the state of a machine, and a sequence of 
reductions may end or may continue forever. 

A small-step semantics for a functional language with imperative features, like 
pScheme or sScheme-, can use an abstract machine with four components: a con- 
trol component e or v, an environment p, a store o, and a continuation S. Such 
a machine is called a CESK machine. In our machine, the continuation S is rep- 
resented as a stack of frames; a frame is (usually) an expression with a hole in it. 
Control operators are implemented by inspecting the evaluation stack and discard- 
ing or copying some of the frames found there. And at any point during evaluation, 
the stack can be used to convert the machine’s state into an incompletely evaluated 
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expression: use € or v to fill the youngest hole in S, then use the result to fill the 
next youngest hole, and so on. 

Although the details are beyond the scope of this book, small-step semantics 
can simplify proofs of metatheoretical results, like “well-typed programs don’t go 
wrong.” Small-step proofs can be simpler than big-step proofs, because a small- 
step proof usually reasons about the effects of a single step, whereas a big-step 
proof uses an induction hypothesis to reason about entire derivations. 


3.8.1 Key words and phrases 


ABSTRACT-MACHINE SEMANTICS A SMALL-STEP SEMANTICS in which transitions 
go between states that include some non-syntactic, machine-like element, 
like a store, an environment, a stack, or a similar data structure. 


call/cc A primitive in full Scheme that takes a function f as argument, captures 
the UNDELIMITED CONTINUATION of the call/cc, and applies f to that con- 
tinuation. Its full name is call-with-current-continuation. 


CALL STACK In a real or virtual machine, a stack of activations of procedures that 
are waiting for younger activations to return. On that call stack, an activation 
typically holds a return address, which tells where to resume execution upon 
returning to the calling procedure. An activation also holds values of formal 
parameters and local variables, or at least that subset of formals and locals 
that don’t fit in machine registers. An activation may also hold saved values 
of machine registers. A call stack may be considered a special case of an 
EVALUATION STACK. 


CONTINUATION In semantics, a representation of the context in which a syntactic 
form is evaluated. A continuation expresses “how the computation contin- 
ues” when the current evaluation is complete. In pScheme-+, a continuation 
is represented by an EVALUATION STACK S. In CONTINUATION SEMANTICS, 
a continuation is typically represented by a mathematical function. 


In code, a representation of computational context to which control can be 
transferred. A continuation may be represented as a function or as a value 
of an abstract type. 


CONTROL OPERATOR A syntactic form that transfers control outside its immedi- 
ate context—that is, away from its parent in the abstract-syntax tree. Con- 
trol operators that transfer control within a procedure, including break, 
continue, and return, are easily dealt with by a compiler. Control opera- 
tors that transfer control between procedures—like throw, longjmp, or rais- 
ing an exception—require run-time support, sometimes involving inspection 
of the CALL STACK. Control operators that capture a continuation, including 
call/cc and CONTROL, typically require the implementation to turn the call 
stack into a data structure. All control operators can be specified using a 
SMALL-STEP SEMANTICS. Control operators in the first two categories can 
be specified by extending a BIG-STEP SEMANTICS with behaviors, as done in 
Chapter 10. 


DELIMITED CONTINUATION A CONTINUATION that represents a computation from 
a point to a delimiter. A delimited continuation behaves like an ordinary func- 
tion: transfer of control to a delimited continuation evaluates the computa- 
tion up to the point where it reaches a delimiter, then returns. Like func- 
tions, delimited continuations may be composed. 


DIVERGENCE Evaluation that doesn’t terminate. 


EVALUATION CONTEXT A syntactic form or data structure commonly used to make 
a REDUCTION SEMANTICS deterministic. An expression to be reduced is de- 
composed into an evaluation context and a REDEX; the context tells where 
the semantics is “looking” to perform the next step of computation. 


EVALUATION STACK The representation of an EVALUATION CONTEXT in the seman- 
tics and implementation of jsScheme+. Not to be confused with the stack 
used for evaluation in PostScript or in the Java Virtual Machine. Contains all 
the information found in a CALL STACK, and more. 


HOLE A technical device used to represent an EVALUATION CONTEXT: an evalua- 
tion context is represented by a program in which a single subexpression is 
replaced by a hole. Evaluating an expression e in that context is equivalent 
to evaluating the original program in which the expression is replaced by e. 


REDEX Short for “reducible expression,” a redex is a form that appears on the left- 
hand side of a reduction rule in a REDUCTION SEMANTICS. 


REDUCTION SEMANTICS A SMALL-STEP SEMANTICS that operates entirely on syn- 
tax. That is, the transitions of the semantics are transitions between syntac- 
tic elements. A typical reduction semantics might simply specify transitions 
between terms, or it might use a term and evaluation context, where the con- 
text is also expressed syntactically. The evaluation of an expression e is de- 
fined by reduction to a value or a normal form, where reduction comprises a 
sequence of zero or more transitions. 


SMALL-STEP SEMANTICS A species of semantics in which the primary judgment 
form captures a single step of computation, where a step, which is the atomic 
unit of computation, is modeled by a transition of a formal system. One ad- 
vantage over a BIG-STEP SEMANTICS is the ability to express a computation 
that loops forever (DIVERGES), like an operating system. Small-step seman- 
tics can also easily express computations that communicate with the outside 
world, and they can easily specify CONTROL OPERATORS. The primary disad- 
vantage of a small-step semantics is its complexity: A small-step semantics is 
usually harder to understand than a big-step semantics; it has a more com- 
plex abstract machine than a big-step semantics; and it usually has about 
twice as many rules as a big-step semantics. 


STRUCTURED OPERATIONAL SEMANTICS A syntactic approach to SMALL-STEP SE- 
MANTICS in which the context for REDUCTION is defined inductively via in- 
ference rules, not by an explicit data structure representing the EVALUATION 
CONTEXT (Plotkin 1981). 


UNDELIMITED CONTINUATION A CONTINUATION that represents “the rest of the 
computation,” that is, the entire EVALUATION STACK at the point where the 
continuation is captured. An undelimited continuation represents what is to 
be evaluated from a point to the end of the program. Transfer of control to an 
undelimited continuation never returns; the undelimited continuation takes 
over. In full Scheme, an undelimited continuation is captured by primitive 
call-with-current-—continuation, usually abbreviated call/cc. 


3.8.2 Further reading 


The most influential complaint ever made about control operators was a note writ- 
ten by Edsger Dijkstra and published in Communications of the ACM as a “letter to 
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the editor” entitled “Go To Statement Considered Harmful” (Dijkstra 1968). Dijkstra 
advocated for structured programming, and his later monograph on the topic was 
collected in book form along with monographs by Ole-Johan Dahl and Tony Hoare 
(Dahl, Dijkstra, and Hoare 1972). Dijkstra eventually supplemented his ideas about 
program structure with deep, powerful ideas about semantics and proofs of pro- 
grams using weakest preconditions, a form of predicate transformer that relies on the 
absence of control operators, even such well-behaved ones as break and continue 
(Dijkstra 1976). Weakest preconditions, which Dijkstra uses to define his language, 
still offer a powerful technique for creating correct procedural programs. Many 
examples can be found in Dijkstra’s (1976) book, which shows polished gems cre- 
ated by a master programmer. While the gems are worth marveling at, if you want 
to learn to apply the techniques yourself, you might start with Bentley (1983) and 
Gries (1981). 

In modern programming, the essential control operators are the ones involv- 
ing exceptions. Exceptions can be implemented with acceptably low overhead; 
the techniques are well known and are described by Drew, Gough, and Leder- 
mann (1995). Exceptions can also be implemented, with greater overhead, using 
setjmp and longjmp; two good examples are presented by Roberts (1989) and Han- 
son (1996, chapter 4). 

Continuations and ideas related to continuations can be found in much of the 
research of the late 1960s and early 1970s (Reynolds 1993). But continuations be- 
came widely known in a form developed by Christopher Wadsworth under the su- 
pervision of Christopher Strachey (Strachey and Wadsworth 2000). Using continu- 
ations, Wadsworth and Strachey found a clean way to give semantics to goto state- 
ments. This work fit into a larger program, led by Strachey and by Dana Scott, on 
what is now called denotational semantics. The results combined Scott’s mathemati- 
cal insights, which identified a well-behaved lattice of mathematical functions that 
could be used to explain recursion, with Strachey’s method of defining the deno- 
tation of an expression (that is, what mathematical object the expression stands 
for) by composing the denotations of its subexpressions. Continuations have since 
been the method of choice for explaining many computational ideas connected to 
control. The work is definitively described by Stoy (1977), an excellent book for the 
mathematically inclined. The less mathematically inclined may prefer textbooks 
written by Allison (1986) or Schmidt (1986). 

“Proper tail calls” are usually defined informally, but a precise, careful defini- 
tion is presented by Clinger (1998)—using a semantics very similar to the one in this 
chapter. 

Abstract machines are not just a semantic technique; they are commonly used 
in programming-language implementation. An implementor designs a machine 
that can be implemented relatively efficiently, then builds a compiler that translates 
source programs into code for that machine. Machines that have been used in this 
way are surveyed by Diehl, Hartel, and Sestoft (2000). 

Small-step semantics are explained in depth by Felleisen, Findler, and Flatt 
(2009), who present major varieties of reduction semantics, including the CESK ma- 
chine on which the semantics of wScheme-+ is based. They also present standard 
theoretical results, of which the most important—the Church-Rosser theorem— 
says essentially that in standard reduction semantics, nondeterminism in the re- 
duction relation is harmless. Finally, they present Redex, a tool for experimenting 
with reduction semantics. 

Reduction semantics, abstract machines, and interpreters for big-step seman- 
tics are more closely related than you might think—so closely that an interpreter 
in the style of Chapter 2 (or more likely, Chapter 5) can be transformed automat- 
ically into an abstract-machine semantics. These relationships have been eluci- 


Table 3.5: Synopsis of all the exercises, with most relevant sections 


Exercises Section Notes 

1to4 3.2 Programming with and without control operators; 
interactions among control operators. 

5 to7 3.4 Analysis and transformation of code with control 
operators. 

8 to 10 3.3, 3.6.1, 3.6.11 Consumption of stack space. 

11 to 14 3.5, 3.6.11 The evaluation stack in the semantics; optimized 
tail calls. 

15 3.5, 3.7.3 The evaluation stack and evaluation contexts. 

16 to 19 3.5 What source code can tell us about the evaluation 
stack. 

20 to 23 3.6 Implementing control operators in the interpreter. 

24and25 3.6 Implementing debugging aids. 

26and27 3.7.4 Call with current continuation (call/cc). 


dated most deeply by Olivier Danvy, his students, and his collaborators; one point 
of entry is Danvy’s (2006) DSc thesis. 

Delimited continuations and a rationale for their design are described by 
Felleisen (1988), who presents the control operators # and F (now called prompt 
and control). The closely related operators shift and reset are described by 
Danvy and Filinski (1990), who include several programming examples. The shift 
and reset operators have engendered significant interest, including a nice tutorial 
with many exercises (Asai and Kiselyov 2011). 

Many examples of programming with undelimited continuations are given by 
Friedman, Haynes, and Kohlbecker (1984), who use call/cc as the main control 
primitive. The expressive power of call/cc is demonstrated by Filinski (1994), 
who shows that a wide variety of abstractions, including shift and reset, can be 
implemented using call/cc and a single mutable storage cell. Unfortunately, Fil- 
inski’s insight is more mathematical than practical; great care is required with as- 
sumptions and corner cases (Ariola, Herbelin, and Herman 2011). A case against 
call/cc is presented by Kiselyov (2012), who argues that Filinski’s techniques are 
brittle because their assumptions are rarely satisfied by large, practical systems. 

Unless you build your entire compiler around continuations, like Appel (1992), 
call/cc is challenging to implement. The challenges are described and met 
by Bruggeman, Waddell, and Dybvig (1996) and by Hieb, Dybvig, and Brugge- 
man (1990). Even though they omit lots of details, these papers are really good. 
A broader view of implementation techniques is provided by Clinger, Hartheimer, 
and Ost (1999). 

Delimited continuations are also challenging; an implementation of shift and 
reset in the Scheme48 virtual machine is nicely described by Gasbichler and Sper- 
ber (2002). The shift and reset operators have also been implemented in a native- 
code compiler for MinCaml (Masuko and Asai 2009). 

If you want a feel for calculi, I recommend Milner’s (1999) monograph on the 
m-calculus; it combines readily accessible examples of concurrent and commu- 
nicating systems with the mathematical foundations needed to prove interesting 
properties. Parts of the book are heavily mathematical, but on a first reading, you 
can skip the theory chapters. 


$3.8 
Summary 


247 


Control operators 
and a small-step 
semantics: juScheme-+ 


248 


3.9 EXERCISES 


The exercises are arranged mostly by the skill they call on (Table 3.5). The best 
exercises involve implementing control operators and reasoning about tail calls. 


* In Exercises 13, 14, and 16, you use the operational semantics to justify tail- 
call optimization and to explain how to optimize evaluation stacks. 


* In Exercises 20 and 21, you implement return and you extend u~Scheme+ 
with unwind-protect. 


3.9.1 Retrieval practice and other short questions 


A. 


In C you can write an if statement with no else. When you want to write 
the same kind of control structure in wScheme-+, what form of expression do 
you use? 


If a throw is evaluated inside a try-catch and the labels match, what happens? 
If a throw is evaluated inside a function with no try-catch, what happens? 


If a throw is evaluated inside a try-catch but the labels don’t match, what hap- 
pens? 

What judgment or judgments of small-step semantics correspond to a single 
judgment of big-step semantics? 


How many rules of small-step semantics are needed to specify what a set ex- 
pression does? What does each rule do? 


When the current item of the abstract machine is a value, most rules inspect 
only the topmost (youngest) frame on the evaluation stack. What forms of 
youngest frame trigger the inspection of older frames? 


What is the name of the optimization implemented by pushenv_opt? What 
does the optimization accomplish? 


When a frame on the evaluation stack holds an expression with a hole in it, 
where is the memory allocated for the struct Exp? 


When you want to tell the interpreter to show you how the stack changes as an 
expression is evaluated, what do you do? 


3.9.2 Programming with and without control operators 


1. Iteration over lists with early exit. Many recursive functions that consume lists 
can also be implemented using loops and control operators. Use loops and 
control operators, but no recursion, to implement functions exists?, al1?, 
and member? from Chapter 2. 


2. Early exit without control operators. Procedural code can be written in the style 
of “structured programming,” that is, using loops but no control operators. 


(a) Reimplement the rainfall function using procedural programming 
but without using break, continue, or return. 


(b) Likewise, reimplement functions all? and member? using while loops 
instead of recursion, but without using break, continue, or return. 


(c) Compare your results with the rainfall-p in chunk 207a and with your 
results from Exercise 1. In what ways are you handicapped if you don't 
have break or continue? How do you compensate? 


3. Nested control operators. Control operators are an imperative feature; the or- 
der in which they are evaluated makes a difference. And many combinations 
of control operators can be simplified. Analyze these combinations: 


(a) Is there a simpler expression that behaves like (return (return 1)) in 
every context? 


(b) Isthere a simpler expression that behaves like (return (continue) ) in 
every context? 
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(d) Is there a simpler expression that behaves like (throw :L (return 3) ) 
in every context? 


(e) Is there a simpler expression that behaves like (return (throw :L 4)) 
in every context? 


(f) Can expression (begin €; €2--- (throw L exn) --- e€,) be replaced 
by (begin €; €2--- (throw L exn)) without changing the behavior of 
the program? 


(g) Can the function application (ee; €2:-- (throw L ern) --- en) be 
simplified without changing the behavior of the program? If so, what 
is the simpler version? If not, why not? 


4. Nested try-catch handlers. Combinations of try-catch with throw are less 
tricky. What outcome do you expect from these expressions, and why? 


(a) (try-catch 
(try-catch (throw :h 'inner) 
th 
(lambda (exn) (list2 'caught exn))) 
th 
(lambda (exn) (liste 'outer-caught exn))) 
(b) (try-catch 
(throw :h (try-catch 'terminated :h 
(lambda (exn) (liste ‘inner exn)))) 
th 
(lambda (exn) (liste ‘outer exn))) 


3.9.3 Analysis and transformation of loops and control operators 


5. Eliminating break from ~Scheme code. A control operator like break can be 
eliminated by a program transformation. (Eliminating unloved control con- 
structs by translating them to while loops and conditions was a nerdy pas- 
time of the 1960s.) Generalize your knowledge from Exercise 2 by defining 
a program transformation that takes as input a uScheme program that uses 
break and produces as output an equivalent wScheme program that does not 
use break. 


Define your program transformation as a ;sScheme function that takes two 
inputs: a pScheme expression to be transformed, represented as an S- 
expression, and a list of names that are guaranteed not to appear in the 
program to be transformed (and can therefore safely be used as variables). 
To represent a sScheme expression as an S-expression, simply put a quote 
mark in front of its source code. 


6. Context for lowering break and continue. Ifa break or continue appears out- 
side any loop, my interpreter reports a “lowering error.” 


(a) Write a proof system for the judgment “e is inside a loop.” The body of 
a lambda expression is not considered to be inside a loop, even if the 
lambda expression itself is inside a loop. 


(b) As noted above, a jsScheme-+ expression can be represented as an S- 
expression by putting a quote mark in front of its source code. Using 
the proof system from part (a), define a function loops-ok? that exam- 
ines any zScheme-+ definition and returns #f if and break or continue 

250 occurs outside a loop, and that returns #f otherwise. 


Control operators 
and a small-step 
semantics: juScheme-+ 


7. Lowering with condition outside the loop. The lowering transformation defined 
by Table 3.4 treats break in such a way that when (while e, €2) is evaluated, 
executing a break within e; terminates the loop. In other words, the lower- 
ing rules treat e; as if it were inside the loop. 


These rules offend me. I think a break within e; should terminate the en- 
closing loop, if any. Define a new lowering transformation that fixes the 
problem. I recommend passing this transformation a long list of labels that 
are all distinct from one another and distinct from the labels : continue and 
zreturn. 


Test your transformation either by implementing it in pzScheme or by modi- 
fying the C code in Section M.3. 


3.9.4 Understanding stack consumption 


8. Stack requirements for fold1 and foldr. A list of 10 numbers can be summed 
using either foldl or foldr. 


(a) Using the option &show-high-stack-mark, measure the amount of 
stack space consumed by fold1 and foldr. 
(b) Look at the source code for foldl and foldr. Using the definition in 
Figure 3.6, identify exactly which calls occur in tail position. 
(c) Use the &trace-stack facility to observe exactly what the stack looks 
like when fold1 and foldr are executing. Based on your observations, 
* Write a formula that correctly predicts the high stack mark for 
summing n numbers using fold1, as a function of n. 
* Write a formula that correctly predicts the high stack mark for 
summing n numbers using foldr, as a function of n. 
(d) Based on your observations and on your analysis of the source code for 
foldl and foldr, justify your formulas. 


9. Implementmap using constant stack space. Implement a new version of map with 
the following property: 


If (f x) uses constant stack space for any x, then (map f xs) uses 
constant stack space, no matter how many elements are in zs. 


You will have to make sure that every recursive call occurs in tail position, and 
you may have to use accumulating parameters. 


10. Compare stack consumption in Scheme and uScheme-+. Write a psScheme func- 
tion and call that make the Scheme interpreter halt with a “recursion too 
deep” error, but which the jsScheme-+ interpreter runs just fine. 


3.9.5 The evaluation stack in the semantics 


11. 


12. 


13. 


Distinguishing saved-environment frames. A frame formed with ENV always re- 
stores the environment, independent of its tag (CALL or NONCALL). So what 
does the tag do, and in which states is it possible to distinguish different tags? 
Considering machine states with one of these frames on top of the evaluation 
stack, answer these two questions: 


(a) Can you choose an environment p, a store o, a stack S, a value v, and 
a saved environment p’ such that (v, p,0, ENV(p’, NONCALL) :: S’) re- 
duces to a different final state than (uv, p,0, ENV(p’, CALL) :: S')? 


(b) Can you choose an environment p, astore a, astack S, an expression e, 
and a saved environment p’ such that (e, p, 0, ENV(p’, NONCALL) :: S) 
reduces to a different final state than (e, p,0, ENV(p’, CALL) :: S')? 


Alternative semantics for long-goto. The semantics of long-goto would be 
far more pleasant if it weren't necessary to push its frame onto the stack. 
A pleasant alternative might look like this: 


F is not LONG-LABEL(L, e) 
- 
(LONG-GOTO(L, e), p,0, F' :: S) + (LONG-GoTO(L, e), p, 0, S) 
(ALTERNATIVE-GOTO-UNWIND) 
F = LONG-LABEL(L, e) 
(LONG-GOTO(L, e), p,0, F :: S) — (e, p, 0, S) 

(ALTERNATIVE-GOTO-TRANSFER) 

Write an expression of Core wScheme-+ that evaluates to #t under the al- 

ternative semantics and to #f under the original semantics. Explain how it 
works. 


Prove that optimizing tail calls is safe. Tail-call optimization is sound only if 
for arbitrary e, v, P, 0, P1, P2, and S, any unoptimized stack of the form 
ENV(2, CALL) :: ENV(p1, CALL) :: S can be replaced with the optimized form 
ENV(p1, CALL) :: S. 


(a) Prove that when the optimized and unoptimized forms are on the top 
of the stack and the current item is a value, the two stacks are indistin- 
guishable. To do so, prove that 


(v, P, 0, ENV(p2, CALL) :: ENV(p1, CALL) :: S') >* (vu, p1,0, 5) 


and 
(v, P, 0, ENV(p1, CALL) :: S') * (v, p1,0, 5S) 


(b) Ife can be evaluated without control operators, so there exist ao’ and v 
such that (e, p,0) 4) (v,o’), we can assume (Exercise 26) that there is 
ap’ such that for any stack S’, (e, 9,0, S") >* (uv, p’,o’, S’). Using this 
assumption, prove that when the current item is such an expression, 
the optimized and unoptimized forms are indistinguishable. That is, 
prove that 


(€, 0, 0, ENV(p2, CALL) :: ENV(p1, CALL) :: S) >* (v, pi,0’, S) 


and 
(e, p, 0, ENV(p1, CALL) :: S') 3* (v, pi, 0", 8). 
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(c) To prepare for cases where the optimized and unoptimized stacks 
have other frames pushed on top of them, prove that if the evaluation 
of (e, p, a, S') does not get stuck or loop forever, then exactly one of the 


following holds: 
° (e, P; 0, S) > (v, p': a’, S) 
> (e,p,0,S) >* (vu, p’,o’, RETURN(e) :: Fy i: Foire +e Fy, 2: S') for 
some (possibly empty) sequence of frames F :: Fy :: +++ 2: Fh. 
> (e,p,0,S) >* (vu, p’,o’, LONG-GOTO(L, @):: Fy :: Fg::+ + Fy) 
for some (possibly empty) sequence of frames PF :: Fy :: +++: Fy. 
(d) Prove that if none of F) :: F ::--- :: F, has the form ENV(p’, CALL), 
then 
(v, p, 0, RETURN(@) 1 Fy: Fit: + iF i: ENV(p2, CALL) ::ENV(91, CALL)::S) 
>" (v, p1,0, 5) 
and 
(v, Pp, 0, RETURN(e):: Fy :: Fotis: Fy: ENV(p1, CALL) :::S) —* (v, pi, 0,9). 


14. More cases for optimizing tail calls. To implement truly proper tail calls, the 
interpreter must simplify every stack that contains consecutive ENV frames, 
regardless of tag. 


(a) In state (e/v, p, 0, ENV(p2, NONCALL) :: ENV(/1, CALL) :: 5), how can 
the stack be simplified? 


(b) In state (e/v, p,0, ENV(P2, CALL) :: ENV(1, NONCALL) :: S), how can 
the stack be simplified? 


(c) In state (e/v, p,0, ENV(2, NONCALL) :: ENV(?1, NONCALL) :: S), how 
can the stack be simplified? 


(d) ENV frames on the evaluation stack are inspected by rules SMALL-STEP- 
RESTORE-ENVIRONMENT, GOTO-UNWIND, GOTO-TRANSFER, RETURN- 
UNWIND, and RETURN-TRANSFER. For each previous part of this prob- 
lem, justify your answer and list the rules you appeal to. 


15. The evaluation stack as evaluation context. Grammars for evaluation contexts 
and stack frames are given in Section 3.7.3. If a hole is represented by the 
pScheme symbol <*>, then both evaluation contexts and stack frames can 
be represented as S-expressions. 


(a) Write a wScheme function that converts an evaluation context to a list 
of frames. 
I would write an auxiliary, recursive function that expects an expres- 
sion, which might or might not be an evaluation context, plus success 
and failure continuations. If the expression turned out to be a context, 
my function would pass the resulting list of frames to the success con- 
tinuation. Otherwise it would call the failure continuation. The base 
case of the recursion would be a hole (success) or some other name or 
literal (failure). The induction step might require a search of several 
subexpressions to see which one represents an evaluation context. 

(b) Write a wScheme function that converts a list of frames to an evaluation 
context. 


This is the easier of the two problems. I would start by defining an aux- 
iliary function that fills the hole in a frame. 


(lambda (%1,...,2n) €) isin the code 


e is in tail position 


(if e€1 €2 €3) is in tail position (if e€1 €2 €3) is in tail position 
€2 is in tail position €3 is in tail position 
(let ([%1 €1] --- [Xp €n]) e€) is in tail position 


e is in tail position 


(letrec ([%1 €1]--+ [@n €n]) €) isin tail position 


e is in tail position 


Figure 3.6: Partial proof system for tail position (Core pzScheme-+) 


3.9.6 What source code tells us about the evaluation stack 


16. 


17. 


18. 


Dynamic context of an expression in tail position. A simple proof system that 
says when an expression “is in tail position” is shown in Figure 3.6. Using 
metatheoretic reasoning about this proof system, prove that if an expression 
is in tail position, then when that expression is evaluated, the top of the stack 
contains a sequence of zero or more frames of the form ENV(p, NONCALL) 
followed by a frame of the form ENV(p, CALL). Try proof by induction over 
a derivation that uses the rules in Figure 3.6. 


Expressions returned and tail position. It’s tempting to say that the e in 
(return e) occurs in tail position. But when e is evaluated, the top of the 
stack does not necessarily contain a sequence of zero or more frames of 
the form ENV(p, NONCALL) followed by a frame of the form ENV(p, CALL). 
It could be made so, however, by these rules: 


F does not have the form ENV(p, CALL) 


(RETURN(€), 0,0, F :: S) — (RETURN(€), p,o, 5)” 
(ALTERNATIVE-RETURN-UNWIND) 


(RETURN(e), p, 0, ENV(p’, CALL) :: S) — (€, p,0, ENV(p’, CALL) :: S)_ 
(ALTERNATIVE-RETURN) 
Solve exactly one of the following two problems: 


(a) Prove thatthe alternative RETURN rules produce the same results as the 
original rules. 


(b) Define a function that uses return in such a way that the original rules 
produce one result but the alternative rules produce a different result. 


Occurrence inside a long-label. Look at Figure 3.6, which defines a little 
proof system to say exactly when an expression occurs “in tail position.” Cre- 
ate a similar proof system to say exactly when an expression occurs “inside 
along label L.” Start with these rules: 


(long-label L e) is in the code (if e€1 €2 €3) is inside long label L 


e is inside long label L € 1 is inside long label L 
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19. Dynamic context of a labeled expression. In Exercise 18, you create a simple 
proof system that says when an expression is inside a long label. 


(a) Using metatheoretic reasoning about this proof system, prove that if 
expression e is inside a long label L, then when e is evaluated, the top 
of the stack contains a sequence of zero or more frames, none of which 
has the form ENV(p, CALL), followed by a frame LONG-LABEL(L, e). 
Try proof by induction over a derivation that uses the rules in your proof 
system. 
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254 with label L, and if expression e evaluates to value v without an er- 
ror, then the long-goto is also evaluated without an error. That is, 
from a state of the form (v, p,7, LONG-GOTO(L, e) :: S), the abstract 
machine makes one successful state transition after another until the 
LONG-GOTO frame is replaced by something else. 


The proof in part (b) guarantees that when break and continue are lowered 
to long-goto expressions, those expressions are evaluated without error. 


3.9.7 Implementing control operators 


20. Implementing return. My interpreter implements long-goto but not return. 
Implement return. 


21. Finalization. When you're writing procedural code, sometimes you want to 
define cleanup code that executes no matter what. The classic example is 
that when you open a file, you want to be sure to close it. In many languages, 
cleanup code is attached to a try-catch using the keyword finally. But we'll 
put cleanup code inside a form called unwind-protect, which comes from 
Common Lisp: 


Evaluating (unwind-protect e, ef) evaluates the body e,. When 
€p is finished evaluating, whether the result is a value or a control 
operation, the machine evaluates the finalizer es before continu- 
ing as e would have. 


The semantics can be expressed in a handful of rules. The rules code “evalu- 
ate finalizer e and then proceed as you would have” by synthesizing a little 
BEGIN expression. 


(UNWIND-PROTECT) 
(UNWIND-PROTECT(€p, ef), 2,0,.5) 


(€, P, 7, UNWIND-PROTECT(e, ef) :: 5) 


(v, P, 0, UNWIND-PROTECT(®, €7)) —> (BEGIN(€/, U), 2,0, 5) 
(UNWIND-PROTECT-VALUE) 


(v, P, 0, RETURN(@) :: UNWIND-PROTECT(e, ef) :: S) 


(BEGIN(€f, RETURN(v)), 9,0, 5) 
(UNWIND-PROTECT-RETURN) 


(v, P, 0, LONG-GOTO(L, ) :: UNWIND-PROTECT(e, ef) :: S) > 
(BEGIN(€, LONG-GOTO(L, v)), p,0, 5) 
(UNWIND-PROTECT-GOTO) 
Implement unwind-protect. Because BEGIN is not part of Core jsScheme+, 
you will need to lower it using function lowerSequence from Appendix M. 


22. 


23. 


Unwinding many frames at once. The rules of the operational semantics say 
that break, continue, return, and throw remove frames from the stack one 
at a time. At each step the abstract machine re-examines the current item 
or topmost frame, even though they won't have changed. Speed things up: 
implement these operators by writing an inner loop that unwinds the stack. 


(a) Can you find a uScheme-+ program for which this change results in a 
measurable difference in performance? 


(b) Is the new code simpler or more complicated than the original code? 
(c) Which version do you like better and why? 


Tail-call optimization in the presence of lowered return. Control operators 
break and continue are implemented by lowering to long-goto, but return 
is not lowered. It could be lowered (Table 3.4), but lowering return would 
complicate tail-call optimization. Confirm this assessment: Implement 
return by lowering it, with proper tail calls. 


(a) Enable lowering of return (define LOWER_RETURN as true in file lower .c). 


(b) As in Exercise 8, 9, or 10, confirm that tail calls are not optimized. 

(c) Update pushenv_opt so that if the top of the stack contains zero or 
more labels followed by another environment frame, no new frame is 
pushed. Inspect the stack using function topnonlabel. 

(d) Update the eval case for (long-label L e) so that if the top of the stack 
contains zero or more labels followed by a LONG-LABEL(L, e) frame 
(with the same L), no LONG-LABEL frame is pushed. 

(e) Confirm that tail calls are optimized again. 


The optimizations of Exercises 22 and 23 can be proven correct using the same 
techniques that are used in Exercise 13. 


3.9.8 Debugging aids 


24. 


25. 


Visualizing just the call stack. To diagnose a fault, a visualization of the stack 
(“stack trace”) can be very helpful. But an evaluation stack includes so much 
information that a complete visualization can be hard to digest. Implement 
a visualization that shows just the active function calls. 


+ Enhance the implementation of the SMALL-STEP-APPLY-LAST-ARG rule 
so that it copies the syntax field of the APPLY frame into the syntax field 
of the ENV frame. 


* Write a C function that takes a Stack and shows the syntax fields of the 
ENV frames that have CALL tags. Arrange for zScheme’s error primi- 
tive to call that function. 


Diagnosing a long-goto with no target. If long-goto is evaluated without a 
corresponding long-label, the interpreter doesn’t discover the error until 
the context is lost. We can do better. Change the interpreter so that if it 
evaluates long-goto, it first checks to make sure that the stack contains a 
LONG-LABEL frame with a matching label. If not, long-goto should show 
what is on the stack, preferably using the function from Exercise 24. 


3.9.9 Continuations 


26. 


Continuation capture. Using the rules in Section 3.7.4, implement call/cc. 


27. Using captured continuations. Implement try-catch and throw using call/cc 


and possibly an additional data structure. 
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Automatic memory management 


No Scheme object is ever destroyed. The reason that 
implementations of Scheme do not (usually!) run out of 
storage is that they are permitted to reclaim the storage 

occupied by an object if they can prove that the object 
cannot possibly matter to any future computation. 


Kelsey, Clinger, and Rees (1998, page 3) 


A running wScheme program continually allocates fresh locations. How are they 
supplied? Memory is limited, and malloc will eventually run out. Memory can be 
recovered using free, butifa programmer must call free, asin C and C++, they risk 
memory errors: leaks, locations that are freed multiple times, and misuse of freed 
locations (so-called dangling-pointer errors). Memory errors can make a program 
crash—or, worse, silently produce wrong answers. But in languages like wScheme, 
full Scheme, Java, and JavaScript, which are memory-safe, such errors are impos- 
sible. The errors are prevented because the implementation of puScheme, not the 
pScheme programmer, figures out when it is safe to reuse a location. The tech- 
niques used to reuse locations safely are demonstrated in this chapter. 

Memory-management techniques might seem like matters for implementors, 
but automatic memory management enables all kinds of designers to keep things 
simple. Language designers can include features that create closures, cons cells, 
and other objects without having to say when the memory they occupy must be 
reclaimed. Software designers can define interfaces that focus on the needs of the 
client; when memory management is automatic, it is not necessary to clutter an in- 
terface with extra functions and/or parameters that address such issues as where 
memory is allocated, who owns it, when it is freed, and how a client can make a 
private copy. Without automatic memory management, interfaces would be more 
complex, programming with higher-order functions would be nearly impossible, 
and object-oriented systems like Smalltalk (Chapter 10) would be much more com- 
plex. Safety guarantees, like those that Java provides, would be impossible. Auto- 
matic memory management underlies all civilized programming languages. 

Automatic memory management is explained in this chapter. The chapter em- 
phasizes garbage collection, the most widely used method of memory management, 
and its implementation in Scheme. (The name “jiScheme” is used generically; 
the language that is actually implemented is uScheme+.) Reference counting, an 
alternative method, is discussed only briefly (Section 4.8). 
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4.1 WHAT GARBAGE IS AND WHERE IT COMES FROM 


The psScheme interpreter uses Value objects in two ways. Temporary values, like 
values v and w computed by the implementation of cons on page 161c, are stored 
in local variables, i.e., locations on the C stack. In cons, for example, local vari- 
ables v and w hold values until they are passed to allocate, and afterward, those 
variables are not used again. But some Value objects are stored in locations allo- 
cated on the C heap, with malloc, because we can't predict how long they will live. 
In particular, every car and cdr of every cons cell is allocated on the C heap, us- 
ing function allocate. Why? Because if a w~Scheme function returns a cons cell, 
there’s no general way to decide whether that cons cell’s car or cdr will be neededin 
a future computation. For the same reason, every location in every environment in 
every closure is allocated on the C heap. In C, of course, a programmer would have 
to call free at an appropriate moment. In Scheme, memory is freed and reused by 
the system. 

How can the system know if an object can be reused? At any given time, a Value 
object may have become unreachable, which is to say there is no way to get to it. 
Objects become unreachable when pointers change, as in these examples: 


* Evaluating the definition (val x '(a b)) makes x point to a newly allocated 
location. In practice, the system allocates many locations: five hold Value 
objects, and one holds an Env link for the top-level environment. In this 
picture, the Env object is labelled env; the unlabelled objects are Values. 


env 4% 
le le, 
La | le le, 
|b | NIL 


If the next definition evaluated is (set x '()), memory now looks like this: 


any ie 
NIL 
[a] yoy 
[b] NIL 


The location associated with x is overwritten, so the four locations holding 
the atom a, the cons cell (b), the atom b, and NIL are now unreachable, and 
they cannot affect any future computation. They can be reused to satisfy 
future allocation requests. 


* Suppose the next definition instead sets x to (cdr x). 
258. (transcript 258) = 283> 
=> (val x '(a b)) 
-> (set x (cdr x)) 


1In order, they are 'b, '(), 'a, a cons cell, and an unspecified value associated with x, which is later 
overwritten to hold a second cons cell. 


The second cons cell is copied over the location containing the first. Now the 


picture is 
any cad 
$4.2 
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NIL 
[e] 259 


The locations containing the atom a and the original copy of the second cell 
of (ab) are now unreachable. 

Locations holding unreachable objects are garbage. In a garbage-collected sys- 
tem, objects are allocated from a managed heap: a collection of memory blocks and 
metadata structures whose mission is to satisfy allocation requests. When the heap 
runs out of memory and so can no longer satisfy allocation requests, the computa- 
tion is halted while a garbage collector reclaims unreachable objects, making them 
available to satisfy future requests. 

Like all forms of memory management, garbage collection has overhead costs. 
The overhead on allocation is bursty: most allocations are fast, but an alloca- 
tion that triggers the garbage collector makes the program pause, at least a little. 
To keep the pauses short, a sophisticated collector runs frequently, in short spurts, 
or even concurrently with the program that is allocating. And total overhead can be 
reduced by making the heap bigger—each collection does about the same amount 
of work as before, but the collector runs less often. 

Garbage collection also imposes memory overhead, but here the story is more 
complicated. A collector requires enough memory to hold all reachable objects, plus 
an additional factor of “headroom,” so the collector doesn’t have to run too often. 
How this requirement compares with manual memory management depends on 
how good the manual manager is at freeing objects that are no longer needed— 
a property that varies from program to program. 

Garbage collection has another pleasant property—as we see in this chapter, 
a garbage-collected heap can easily be integrated into existing code; one simply 
replaces malloc with a new allocator, them implements free as a no-op. 

A garbage collector scans the roots of a system and uses these roots to find reach- 
able objects. There are many variations, but they all draw from the two methods 
presented in this chapter: mark-and-sweep and copying collection. 

An alternative not based on reachability is reference counting. In reference 
counting, each object stores a count of the number of pointers to that object; when 
the count goes to zero, the object can be put on a list of available objects. Reference 
counting cannot easily reclaim cyclic garbage: an unreachable circular list has no 
objects with zero counts, so it never gets reclaimed. For this reason and others, 
garbage collection is normally preferable to reference counting (Section 4.8). 


4.2 GARBAGE-COLLECTION BASICS 


A managed heap has at least two components: a garbage collector and an allocator. 
The garbage collector gets all the attention, but the allocator shouldn't be over- 
looked; the two work as a team. The team serves a third actor: in the perverse 
jargon of garbage collection, the client code that allocates objects and does useful 
work with them is called the mutator. 
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The best managed heaps use multiple processor cores and multiple threads of 
control to supply the mutator with new objects while disrupting its work as little 
as possible (Section 4.9). But to make the basic ideas concrete, the examples in 
this chapter use a much simpler model, called stop the world. The mutator runs in 
a single thread, and it periodically allocates a new object or changes (mutates) a 
pointer in an old object. (Itis the accumulation of mutations that eventually makes 
objects unreachable.) The allocator satisfies a typical request quickly, but when it 
cannot do so, it suspends execution of the mutator entirely—“stopping the world’— 
and runs the garbage collector in that same thread. 

The system in this chapter makes one other simplifying assumption: that every 
object allocated on the heap is the same size. 


4.2.1 Performance 


The performance of a managed heap can be measured along several dimensions. 
I focus on these three: 


+ Allocation cost. How long does it take to allocate an object? 


* Collector overhead. How much additional work, per object allocated, does it 
take to run the garbage collector? 


* Memory overhead. How much additional memory, per object, does it take to 
hold the data structures that support the managed heap? 


The first two measures combine to give the cost per allocation, measured in time. 
The third measure gives the space overhead of garbage collection, e.g., the ratio of 
the size of the whole heap to the size of the program’s data. In garbage-collected 
systems, space can be traded for time by adjusting the size of the heap: Provided 
there’s enough physical memory, enlarging the heap lowers the cost per allocation. 
The size of the heap is written H. 

A fourth measure is also worth keeping in mind: 


* Pause time. How long does the program pause while the garbage collector is 
running? 


This measure matters most in programs that must interact with users or on servers 
that must answer requests promptly. And it can be improved by another trade-off: 
pause times can be decreased by spending more overhead per allocation. The state 
of the art keeps improving; at one time, a collector with a 50-millisecond pause time 
could claim to be “real-time.” As I write, general-purpose implementations of Go 
and OCaml get pause times under 10 milliseconds, and “real-time” means under 
1 millisecond, if not better. Human reaction time is only about 100 milliseconds, 
so 10-millisecond pause times make garbage collection very effective in interactive 
applications. 


4.2.2 Reachability and roots 


As shown in the examples above, heap-allocated objects can become irrelevant as 
a program runs. And they can do so in an unpredictable manner and at unpre- 
dictable times. A heap object may be used immediately and never needed again, 
or it may be bound into a global environment and live for the rest of the session. 
Whether any particular heap object is relevant to any future computation is unde- 
cidable in general. Luckily, the set of relevant heap objects can be approximated. 


The approximation is reasonably good, reasonably cheap to compute, and reason- 
ably easy to implement. 

The approximation is defined by observing that the interpreter’s state includes 
pointers to data structures, which themselves include pointers, and so on. If, by 
following such pointers, the interpreter can reach an object allocated on the heap, 
then that object is reachable. Because any reachable object might be used in a future 
computation, a reachable object is considered live data. Any object that cannot be 
reached is unreachable and can safely be reclaimed. 

Live data is defined by induction. The base case is given by a set of roots, which 
are enumerated below; roots are live by definition. The induction step says that any 
object pointed to by a live object is itself live. All live data can therefore be found 
by starting at the roots and tracing pointers. The amount of live data is written L. 

In compiled code, roots are found in three places: 


* Global variables from which heap-allocated objects might be reachable 


* Local variables and formal parameters, anywhere on the call stack, from 
which heap-allocated objects might be reachable 


* Hardware registers from which heap-allocated objects might be reachable 
In our wScheme-+ interpreter, roots are found in the same three places: 


* Global variables are stored in a data structure roots.globals which has type 
Env. (jsScheme-+ also has a species of “hidden” global variable: the list of 
pending unit tests. Each list of pending unit tests is associated with a source 
of definitions, and a list is stored in data structure roots.sources of type 
Sourcelist.) 


* Local variables and formal parameters are stored in ENV frames on the eval- 
uation stack (Chapter 3), a data structure roots.stack of type Stack. 


* The closest thing to a “hardware register” is a local variable in C code. 
Their addresses are recorded in a data structure roots.registers of type 
Registerlist. 


Tricolor marking 


The allocated objects, together with the pointers between them, form a graph. Fol- 
lowing pointers amounts to tracing the edges of this graph. Tracing algorithms are 
modeled using an abstraction called tricolor marking. In the model, each object is 
colored as follows: 


« A white object has not been visited by the garbage collector. 
+ A gray object has been visited, but not all of its successors have been visited. 


+ A black object has been visited, and so have all of its successors. 


The colors are abstractions; even in the simple collectors we build in this chapter, 
nodes aren't colored white, gray, or black directly. Instead, an object’s color is iden- 
tified by looking at other properties. Abstracting over the representation in this 
way requires extra thinking, but it pays off because tricolor marking can guide the 
implementation of many different kinds of collectors. 

The easiest payoff comes from the coloring invariant: no black object ever points 
to a white object; black objects point only to gray objects or to other black objects. 
Another payoff comes from an abstract description of how a collector works; mark- 
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and-sweep and copying collectors use different algorithms to traverse the graph of 
objects, but abstractly, both algorithms fit this description: 


color all the roots gray 
while there is a gray object remaining 
choose a gray object 
if the object has a white successor 
color that successor gray 
else 
color the gray object black 


This algorithm maintains the coloring invariant. Moreover, it terminates: there 
are finitely many objects; every gray object eventually becomes black; and no black 
object changes color. When the algorithm terminates, the heap contains only black 
and white objects. The black objects are exactly those reachable from the roots: the 
live data. The white objects are unreachable, and they can be reused. 

The coloring abstraction does not fully specify an algorithm: it does not say 
which gray object to pick next or which white successor to color gray. Most modern 
collectors choose objects in depth-first order. Our simple, stop-the-world copying 
collector, however, chooses objects in breadth-first order. 


4.2.3 Heap growth 


In addition to recovering and reusing unreachable objects, the garbage collector 
manages the size of the heap. At minimum, the collector must ensure that the heap 
is large enough to hold all the program’s live data. For example, if the mutator 
computes a list of all permutations of a list of length n, just holding the answer 
requires n! lists of n elements. If there are not enough objects available on the 
heap, the program is doomed to fail. 

Older collectors didn’t worry about the size of the heap: in the very first garbage- 
collected systems, the computer ran one program at a time, and that program ran 
in all of physical memory. The collector's big challenge was to get reasonable per- 
formance when the heap was almost full. For example, if H — L = 1, then there is 
just one free location, and the garbage collector has to run after every allocation. 
Very expensive. 

Now most garbage collectors run in virtual memory. A collector must keep the 
heap small enough so that virtual memory performs well, while keeping it large 
enough so that overhead is not too high. A collector might start with a fairly small 
heap, then enlarge it in response to the growth of live data. To amortize the costs 
of enlarging the heap, the collector may enlarge it in fairly big chunks, e.g., many 
virtual-memory pages. 

How should the heap grow? That is a hard question to answer well. This book 
uses a simple rule of thumb: maintain a roughly constant ratio of heap size to live 
data, which we write y = a. The inverse, 4 = a measures the fraction of heap 
memory that is used to hold the program’s data. As we see below, 7 bounds the 
fraction of memory that holds no data, and it also is a good predictor of the over- 
head of garbage collection. Changing y can adjust space-time trade-offs. When 
7 is too small, there are too few allocations between collections, and the overhead 
of collection gets high. When 7 is at least 2, mark-and-sweep collectors perform 
very well. For a copying collector, y of at least 3 is needed (Hertz and Berger 2005). 
By comparison, 7 in the range of 1.1 to 1.4 appears to be enough for standard im- 
plementations of malloc and free (Wilson et al. 1995; Johnstone and Wilson 1998). 

Pushing y up to 5 or 7 can reduce garbage-collection overhead substantially. 
The larger 7 requires a larger heap, which means that more memory holds no data, 


but the memory is not wasted. The memory is used to reduce time: time spent 
allocating, time spent collecting, time spent worrying whether objects in a pro- 
gram need to be freed explicitly, or time spent tracking down memory leaks, dou- 
ble frees, and dangling-pointer errors. Space is traded for time in other dynamic- 
allocation systems as well; for example, fast implementations of malloc may re- 
quire heaps 1.4 to 2 times larger than a simple first-fit implementation (Grunwald 
and Zorn 1993). 


4.3. THE MANAGED HEAP IN WSCHEME+ 


In areal Scheme system, all dynamically allocated objects are allocated on the man- 
aged heap. In uScheme-+, only objects of type Value are allocated on the managed 
heap. This design is not realistic, but it keeps the interpreter simple enough to 
study and modify. And the Value objects account for most memory use; objects 
of types Exp, Explist, and Namelist are allocated only by the psScheme parser, so 
their allocation is bounded by the amount of source code. In a real garbage collec- 
tor, the techniques we use for Values would be used for objects of all types. 


4.3.1 Where are Value objects stored? 


Not all Value objects are allocated on the heap. In particular, intermediate values 
computed by eval are either stored in the C local variable v or are stored in evalu- 
ation contexts on the jScheme-+ stack (Chapter 3). As far as the garbage collector 
is concerned, these objects act as roots—values reachable from the stack could be 
used in future computations. 

Allocating most intermediate values on the stack reduces heap allocation to just 
three situations: 


* When the primitive cons is applied, the locations needed to hold the car and 
cdr are allocated on the managed heap, with allocate. 


When an environment is extended—whether it is by a function call, a LET 
form, or a definition—it is extended using the C function bindalloc or 
bindalloclist, both of which call allocate. The allocation is specified in 
the operational semantics: In the rules for these forms, allocation is spec- 
ified by premises of the form ¢,,...,, ¢ domo. Such a premise means 
“call allocate for fresh locations (1,..., 0.” 


When source code is parsed, if it contains a quoted S-expression, space for 
that S-expression is allocated with allocate. 


Objects allocated on the heap can be identified by this invariant: if a pointer to a 
Value exists in another data structure, such as another Value, an Exp, or an Env, 
the pointer points to a location allocated on the heap. 


4.3.2 Reachability of locations 


Any pointer to a Value allocated on the heap has to be findable during garbage 
collection. Such a pointer might be embedded into other data. These data are po- 
tential roots. 


A. Any structure or pointer that might contain a pointer to a Value allocated on 
the heap is a potential root of category A. Their types are: 


* Value*, which points directly to a heap-allocated object 
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Value, through pair.car and pair.cdr 


Env, through loc 


B. Any structure or pointer that might contain or point to a potential root of 
category A is itself a potential root of category B. To avoid infinite regress, 
any structure or pointer that might contain or point to a potential root of 
category B is also a potential root of category B. Their types are: 


Valuelist, because the hd field contains a Value 

Exp, because literal is a Value 

Lambda, because body is an Exp 

Value again, through closure 

Exp again, through lambda or the many Exp*s it contains 
Env, through t1 

Explist, because the hd field contains an Exp 

Valuelist again, because the t1 field points to a Valuelist 
Frame, because the context and syntax fields contain or point to Exps 
Stack, because its frames points to an array of Frames 

Def, because it can point to Exps 

UnitTest, because it contains Exps 

UnitTestlist, because it contains UnitTests 

XDef, because it can contain a Def or a UnitTest 

Source, because tests is aUnitTestlist (see Appendix N) 


Sourcelist, because the hd field contains a Source (also in Appendix N) 


The list above shows not only from which types of value a heap object might be 
reachable but also which pointers to follow from such a value to reach the heap 
object. Accordingly, for each type above, I have written a procedure that follows 
pointers and marks heap-allocated values. These procedures appear in Sections 
4.4.2 and N.1.1. 


4.3.3 Interface to the managed heap: Roots, allocator, initialization 


The managed heap offers this contract to the mutator: 


* The mutator can get a fresh location by calling allocate. 


* When it calls allocate, the mutator must tell the garbage collector about any 
previously allocated location that it might still care about. 


* To improve performance, the garbage collector might move heap objects. 
If so, it faithfully updates every pointer to every moved object. 


To enable the managed heap to fulfill this contract, the mutator and the heap share 
information: 


* They agree on a representation of roots. Ours is shown below. 


* The garbage collector knows enough about the mutator’s internal data struc- 
tures so it can find pointers. In our case, the garbage collector knows every- 
thing about the mutator’s data structures—the information about pointers is 
summarized in the previous section. 


The roots are 


1. The global variables, which include both the user program’s variables (the 
pScheme-+ global environment) and any global variables internal to the mu- 
tator (the pending unit tests) 


2. Local variables and actual parameters of any uScheme-+ function, all of 
which are found on the stack of evaluation contexts 


3. Local variables and actual parameters of any C function that calls allocate 
or a function that could allocate (such as bindalloc or bindalloclist) 


The roots are represented as follows: 


265a. (structure definitions used in garbage collection 265a)= (S377c) 
struct Roots { 
struct £¢ 
Env *user; // global variables from the user's program 
struct £¢ 
UnitTestlistlist pending_tests; // unit tests waiting to be run 
3 internal; // the mutator's internal variables 
} globals; // all the global variables 
Stack stack; // the uscheme+ stack, 
// with all parameters and locals 
Registerlist registers; // pointers to "machine registers" 
3; 


This struct is the data structure that is shared between the mutator and the garbage 
collector, as a global variable: 


265b. (global variables used in garbage collection 265b) = ($3774) 
extern struct Roots roots; 


The mutator makes sure that before any call to allocate, roots is up to date and 
contains pointers to all locations that could affect the rest of the computation. The 
garbage collector inspects the roots and also updates pointers to objects that it 
moves. Register roots are added and removed in last-in, first-out order using func- 
tions pushreg and popreg. 
265c. (function prototypes for 4Scheme+ 265c)= (S358) 265d > 
void pushreg(Value *reg); 
void popreg (Value *reg); 
If the pointer passed to popreg is not equal to the pointer passed to the matching 
pushreg, it is a checked run-time error. 
The mutator may also need to push or pop all the registers on a list of values. 
265d. (function prototypes for Scheme+ 265c) += (S358) <1265c 281la> 
void pushregs(Valuelist regs); 
void popregs (Valuelist regs); 
The rest of the interface supports allocation. The managed-heap function 
allocloc provides an uninitialized location; in chunk 266b, it is used to implement 
allocate. 


265e. (function prototypes for 4Scheme 265e)= (S318a $358) 266a> 
Value *allocloc(void); 


The allocator and roots structure are related by this precondition: clients may call 
allocloc only when all objects that could lead to live values appear in roots. The 
copying collector’s implementation of allocloc also requires that, when called, all 
pointers to allocated values must be reachable from roots, so that they can be updated 
when the values move. 
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The mutator has one more obligation: before calling allocloc, it must call 
initallocate, passing a pointer to the environment that holds the global variables. 


266a. (function prototypes for 4Scheme 265e) += (S318a $358) <265e 
void initallocate(Env *globals); 


The managed-heap interface is implemented in Appendix N. 


4.3.4 Using the heap interface: Scheme allocation 


Functions pushreg, popreg, and allocloc are used to implement the allocate 
function of Chapter 2. 


266b. (loc.c 266b)= 
Value* allocate(Value v) £¢ 


pushreg(&v); 

Value *loc = allocloc(); 
popreg(&v); 

assert(loc != NULL); 
*loc = v; 


return loc; 
3 
What’s new here are the calls to pushreg and popreg. When v is a cons cell and 
allocloc happens to call the garbage collector, pushreg and popreg prevent the 
garbage collector from reclaiming the locations pointed to by v.pair.car and 
v.pair.cdr. The call to pushreg makes v a “machine register” and ensures that 
the collector treats it as a root. And if the collector happens to move v’s car and 
cdr, it updates v’s internal pointers to point to the new locations. 


4.4 MARK-AND-SWEEP COLLECTION 


The original garbage-collection technique, invented by McCarthy (1960) for Lisp, is 
called mark-and-sweep. It allocates available objects from a data structure called the 
free list. To track when objects become available, it uses an extra bit for each object, 
called the mark bit. These data structures support conceptually simple algorithms 
for allocating and recovering objects: 


1. When an object is requested, look for a suitable object is on the free list. 
If there isn’t one, ask the collector to recover some objects. 


2. Remove an object from the free list and return it. 
The collector recovers objects in two phases: 


1. Mark (i.e., set the mark bit associated with) every reachable object. This 
phase traverses the heap starting from the roots. 


2. Sweep every object in the heap. Unmarked objects are unreachable. Place 
each unreachable object on the free list, and clear the mark bit associated 
with each reachable object. 


If these algorithms are implemented naively, the sweep phase visits the entire 
heap. That’s a lot of objects, and they probably don’t all fit in the cache. The mu- 
tator might pause for a long time. Or the allocator could do the sweeping. It too 
must visit the entire heap, but the visit is spread out over many allocation requests. 
Since the collector only has to mark, its running time drops. In this variant, called 
lazy sweeping, the allocator keeps a pointer into the managed heap, advancing the 
pointer one or more objects until it encounters one that can be reused. Such an 
allocator is sketched below; in Exercise 8, you complete the sketch. 


4.4.1 Prototype mark-and-sweep allocator for Scheme 


A mark-and-sweep system associates a mark bit with each heap location. To keep 
things simple, I don’t try to pack mark bits densely; I just wrap each Value in an- 
other structure, which holds a single mark bit, live. By placing the Value at the 
beginning, I ensure that it is safe to cast between values of type Value* and type 
Mvalue*. 


ivate declarati k-and: lect = se 
267a. (private declarations for mark-and-sweep collection 267a)= 267¢ > Mark-and-sweep 
typedef struct Mvalue Mvalue; ect 
struct Mvalue { oon 
Value v; 267 
unsigned live:1; 
3; 
The use of mark bits has to be announced to my debugging interface (Section 4.6.1). 
267b. (ms.c 267b)= 267e> 
bool gc_uses_mark_bits = true; 
The MValue structures are grouped into pages. A single page holds a contigu- 
ous array of objects; pages are linked together into a list, which forms the heap. 
The page is the unit of heap growth; when the heap is too small, the collector calls 
malloc to add one or more pages to the heap. 
267¢. (private declarations for mark-and-sweep collection 267a) += <1267a 267d> 
#define GROWTH_UNIT 24 /* increment in which the heap grows, in objects */ 
typedef struct Page Page; 
struct Page { 
Mvalue pool[GROWTH_UNIT]; 
Page *tl; 
3; 
The t1 field links pages into a list that is referred to by multiple pointers. Pointer 
pagelist points to the head of the list, that is, the entire heap. The “heap pointer” 
hp points to the next Mvalue to be allocated. And heaplimit points to the first 
Mvalue after the current page, curpage. 
267d. (private declarations for mark-and-sweep collection 267a) += 1267¢ 268c> 
Page *pagelist, *curpage; 
Mvalue *hp, *heaplimit; 
The pointers and page list look like this: 
pagelist curpage 
al o>" | 
hp ee allocloc 265e 
Med type Env 153a 
heaplimit epnnee 265¢ 
pushreg 265c 
White areas have been allocated; areas marked in gray diamonds are available for type Value A 


allocation. Pages except the current one are entirely used. The number of unallo- 
cated cells in the current page is heaplimit — hp. 
A fresh page is made current by makecurrent. 


267e. (ms.c 267b) += <1267b 268a> 
static void makecurrent(Page *page) {¢ 
assert(page != NULL); 
curpage = page; 
hp = &page->pool[0]; 
heaplimit = &page->pool[GROWTH_UNIT]; 
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When the heap grows, it grows by one page ata time. Each new page is allocated 
with calloc, so its mark bits are zeroed. 
268a. (ms.c 267b) += <1267e 269b> 
static void addpage(void) { 
Page *page = calloc(1, sizeof (*page)); 
assert(page != NULL); 
(tell the debugging interface that each object on page has been acquired 282d) 


if (pagelist == NULL) { 
pagelist = page; 

3 else § 
assert(curpage != NULL && curpage->tl == NULL); 
curpage->tl = page; 

3 


makecurrent (page); 


3 


It isa checked run-time error to call addpage except when pagelist is NULL or when 
curpage points to the last page in the list. 
Writing the allocator is your job (Exercise 8). But I provide a prototype that does 
not collect garbage; when it runs out of space, it adds a new page. 
268b. (ms.c [prototype] 268b)= 269¢ > 
Value* allocloc(void) £¢ 
if (hp == heaplimit) 
addpage(); 

assert(hp < heaplimit); 

(tell the debugging interface that &hp->v is about to be allocated 282e) 

return &(hp++)—>v; 


4.4.2 Marking heap objects in wScheme 


If the heap is a directed graph containing objects of different types, the collector’s 
marking phase is a depth-first search. Starting at the roots, for each object, the 
collector visits the objects it points to. When the collector visits a Value allocated 
on the heap, it sets the mark bit. If it visits such a Value and the mark is already set, 
it returns immediately; this test guarantees that the mark phase terminates even if 
there is a cycle on the heap. 

The search itself is straightforward; it uses one procedure for each type of object 
to be visited. Not every type in Section 4.3.2 requires a visiting procedure, because 
not every type of object is reachable. For example, an object of type Valuelist 
cannot be reached by following pointers from roots. 


268c. (private declarations for mark-and-sweep collection 267a) += <1267d 
static void visitloc (Value *loc); 
static void visitvalue (Value v); 
static void visitenv (Env env); 
static void visitexp (Exp exp); 
static void visitexplist (Explist es); 
static void visitframe (Frame *fr); 
static void visitstack (Stack s); 
static void visittest (UnitTest t); 
static void visittestlists (UnitTestlistlist uss); 
static void visitregister (Register reg); 


static void visitregisterlist (Registerlist regs); 
static void visitroots (void); 


To make visitenv work, I must expose the representation of environments. 
(In Chapter 2, this representation is private.) 
269a. (structure definitions for uScheme+ 269a)= (S358) 

struct Env £{ 
Name name; 
Value *loc; 
Env tl; 

3; 

Most “visit” procedures are easy to write. As an example, the visit procedure 
for an environment visits all of its loc pointers. 
269b. (ms.c 267b) += 

static void visitenv(Env env) £~ 
for (; env; env = env->tl) 
visitloc(env->loc); 


<1268a 269d> 


3 
The most important such procedure visits a location and sets its mark bit. Un- 
less the location has been visited already, its value is also visited. 


269c. (ms.c [prototype] 268b) += <1268b 
static void visitloc(Value *loc) ¢ 
Mvalue *m = (Mvalue*) loc; 
if (!m->live) £ 
m->live = 1; 
visitvalue(m->v); 


3 
In the tricolor-marking story, if m->live is not set, then mis white. Setting m->live 
makes m gray, and after m—>v is visited, mis black. 
A register is different from a heap location: a register has no mark bit. 


269d. (ms.c 267b) += <1269b 269e> 
static void visitregister(Value *reg) { 

visitvalue(*reg); 
3 


Function visitvalue visits a value’s components of type Value *, Exp, and Env. 


269e. (ms.c 267b) += <1269d 
static void visitvalue(Value v) £ 

switch (v.alt) { 

case NIL: 

case BOOLV: 

case NUM: 

case SYM: 

case PRIMITIVE: 
return; 

case PAIR: 
visitloc(v.pair.car); 
visitloc(v.pair.cdr); 
return; 

case CLOSURE: 
visitexp(v.closure.lambda.body); 
visitenv(v.closure.env); 
return; 

default: 
assert(0); 
return; 


3 


assert(0); 
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curpage 267d 
type Env 153a 
type Exp A 
type Explist S309b 
type Frame 223 
heaplimit 267d 
hp 267d 
makecurrent 267e 
type Mvalue 267a 
type Name 43a 
type Page 267¢c 
pagelist 267d 
type Register 

$377b 
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$377b 
type Stack 223 
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The remaining visit procedures appear in the Supplement (Section N.1.1). 


4.4.3 Performance 


The cost of any single allocation can’t easily be predicted—from the source code, 
you can’t tell which allocation might trigger a garbage collection or how much data 
might be live at that time. Proper cost accounting requires an amortized analysis, 
which considers a sequence of allocations: an entire garbage-collection cycle. In 
that cycle, the garbage collector runs once, and the allocator is called N times, right 
up to just before the next time the collector runs. In a cycle, the allocator sweeps 
all H cells, of which L are marked live, so N = H — L. 

As a simplifying assumption, suppose that the heap is in “steady state,” i.e., H, 
LL, and y do not change from one cycle to the next. Because real heaps often grow 
and shrink wildly, this assumption seldom holds in practice, but it still helps predict 
and compare the costs of different garbage-collection techniques. 


+ Allocation cost. For mark-and-sweep, the cost per allocation is a constant (for 
finding and returning an unmarked cell), plus some fraction of the sweeping 
cost for the whole heap. On average, sweeping imposes a small cost per ob- 
ject (Exercise 14). And with high probability, the cost per object is bounded 
by a small constant (Exercise 16). 


Collector overhead. The garbage collector does work proportional to the size 
of the live data, not the size of the entire heap. Work per allocation is this 
work divided by the number of allocations, so proportional to 4. The work 
itself is depth-first search and setting mark bits. Setting a mark bit seems 
relatively inexpensive, but the pattern of accesses to mark bits in memory 
can be very irregular—so unlike sweeping, marking is not cache-friendly. 


Memory overhead. A mark-and-sweep system pays up to five memory over- 
heads: 


- Every object needs a mark bit. If there is not already a bit available 
in the object header, the mark bits can be pushed off into a separate 
bitmap—although a bitmap militates against parallel garbage collec- 
tion. 


- The mark phase must know where to find pointers in heap objects. 
Ours uses the same alt field that is used to identify the type of a value, 
paying no additional overhead. In real systems, the overhead is kept 
low using a variety of tricks. 


- Amark-and-sweep system requires y > 1 to perform well. While y can 
be adjusted through a wide range, letting y get too close to 1 results 
in poor performance. The necessary headroom may be considered a 
memory overhead. 


- When used to allocate objects of different sizes, a mark-and-sweep sys- 
tem may suffer from fragmentation. That is, it may have chunks of free 
memory that are too small to satisfy allocation requests. Classic analy- 
ses of fragmentation in dynamic memory allocators (Knuth 1973; Wil- 
son et al. 1995) also apply to mark-and-sweep allocators. 


- The mark phase needs a place to store gray objects. Because our mark 
phase uses recursive visiting procedures, it stores gray objects in lo- 
cal variables on the C call stack. This technique is OK if the graph of 


heap objects does not contain very long paths, but a data structure, of- 
ten called a work list, stores gray objects more compactly. A work list is 
usually a stack or a queue. 


* Pause time. On average, allocation is fast, even when the allocator has to 
sweep past marked objects. But when an allocation triggers a garbage col- 
lection, our whole system pauses long enough for the collector to mark live 
data. If there is a lot of live data, such a pause may be too long for real-time 
response, but it is still better than the naive version, which waits for the col- 
lector to sweep the entire heap. Collectors that run in time proportional to 
the amount of live data are effective for many applications. 


4.5 COPYING COLLECTION 


The copying method of garbage collection, also called stop-and-copy, trades space 
for time. A copying system uses roughly twice as much heap as a mark-and-sweep 
system, and while the mutator is running, it leaves half the heap idle. The idle half 
eventually supplies contiguous free space that can be used to satisfy future alloca- 
tion requests, making allocation blindingly fast. It works like this: 


* The heap is divided into two equal semispaces, only one of which is normally 
in use. That semispace, called from-space, is itself divided into two unequal 
parts: The first part contains objects that have been allocated, and the sec- 
ond contains memory that is available for allocation. The boundary between 
them is marked by the heap pointer hp. Available memory is contiguous, not 
fragmented into objects on a free list. Each new object is allocated from the 
beginning of the available memory, by advancing the heap pointer. The heap 
looks like this: 

hp heaplimit 


WW 


Within from-space, on the left, the white area holds allocated objects, and 
the area filled with gray diamonds is unallocated. The end of the unallo- 
cated area (and the semispace) is marked by the limit pointer heaplimit. 
The striped area is not used during allocation. 


Memory is allocated by incrementing hp. The white area grows and the gray- 
diamond area shrinks until all of from-space contains allocated objects, and 
there is not enough gray-diamond area to satisfy an allocation request: 


hp 
heaplimit 


AW 


* When the unallocated area is used up, the system switches to the other semis- 
pace, called to-space. Before the switch, the garbage collector copies all the 
reachable objects from from-space into to-space. Because not all objects are 
reachable, there is room left over in to-space to satisfy future allocation re- 
quests. The system then “flips” the two spaces, and it continues executing 
in to-space; the allocator starts taking new memory from the first location 
above the copied objects. 
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After a flip, the heap might look like this: 


hp heaplimit 


W 


About 20% of objects have survived the collection, and 20% of a semispace 
is 10% of the heap, so y is about 10. In this example, because so few objects 
have been copied relative to the number of past allocations, the copying sys- 
tem performs very well indeed. 


4.5.1 How copying collection works 


A copying collector has something in common with the “marshallers” used to send 
structured data in distributed systems; both components move data from one place 
to another.* To preserve sharing and cycles, a copying collector must copy each 
live object exactly once—and once the object has been copied, the collector must 
keep track of where the copy is. Luckily, the collector has a handy place to store 
the information: the vacated spot from which the object was copied. The collector 
uses that space to store a forwarding pointer. A forwarding pointer indicates that 
an object has already been copied, and it points to the location of the copy in to- 
space. In our Scheme system, a forwarding pointer is represented by a new form 
of value, with tag FORWARD.* A second new form, INVALID, is used for debugging; 
dead cells can be marked INVALID. 

272a. (value.t 272a)= 

Lambda = (Namelist formals, Exp body) 


Value = NIL 
BOOLV (bool) 
NUM (int) 
SYM (Name) 
PAIR (Value *car, Value *cdr) 


CLOSURE (Lambda lambda, Env env) 
PRIMITIVE (int tag, Primitive *function) 
FORWARD (Value *) 

INVALID (const char *) 


A copying collection adjusts every pointer to every live object so that it points 
into to-space; the adjustment is called forwarding the pointer. When p points to an 
object in from-space and *p has not yet been copied, the collector copies *p to *hp. 
When *p has already been copied, tag p->alt identifies p->f orward as a forwarding 
pointer, which the collector returns without copying *p a second time. 
272b. (forward pointer p and return the result 272b)= (278a) 

if (p->alt == FORWARD) { 
return p->forward; 


3 else § 
(tell the debugging interface that hp is about to be allocated 282) 
*hp = *p; 
*p = mkForward(hp); /* overwrite *p with a new forwarding pointer */ 


return hp++; 


3 


The copying component of a garbage collector has sometimes been used as a marshaller. 
3The FORWARD tag is not strictly necessary; a forwarding pointer can be identified simply by its value. 
A pointer is a forwarding pointer if and only if it points into to-space. 


The copy operation never runs out of space because while pointers are being for- 
warded, hp points into to-space at the boundary between allocated and unallocated 
locations. Because to-space is as big as from-space, and because no object is copied 
more than once, to-space always has room for all the live objects. 

The pointers that need to be forwarded and the objects that need to be copied 
can be explained by the tricolor marking scheme. 


+ An object is white if it is sitting in from-space. If it is reachable, it will need 


to be copied. $4.5 
Copying collection 
* An object is gray if it has been copied into to-space, but the pointers it con- 
tains have not been forwarded. The objects it points to may not have been ie 
copied. 
+ An object is black if it has been copied into to-space, and the pointers it con- 
tains have been forwarded. This implies that the objects it points to have also 
been copied into to-space. 
The boundary between black objects and gray objects is marked by an additional 
pointer, scanp. An object’s color is determined by its address a. White objects 
satisfy fromspace < a < fromspace + semispacesize. Black objects satisfy 
tospace < a < scanp. And gray objects satisfy scanp < a < hp. 
All four pointers are shown in this picture: 
fromspace tospace scanp hp 
tf 
Black objects point to to-space; gray objects point to from-space. 
As always, collection begins with the roots, making the objects they point to 
gray. The collector then turns gray objects black until there aren’t any more gray 
objects. In concrete terms, it first forwards all the pointers that are in roots, then 
forwards pointers in gray objects until there are no more. 
273. (copy all reachable objects into to-space 273) = 
t 
Value *scanp = hp = tospace; /* no black or gray objects yet */ 
scanenv(*roots.globals.user); 
for (Frame *fr = roots.stack->frames; fr < roots.stack->sp; fr++) 
(scan frame *f r, forwarding all internal pointers $366b) 
for ( UnitTestlistlist testss = roots.globals.internal.pending tests 
; testss 
; testss = testss->tl hp 276b 
) mkForward A 
(scan list of unit tests testss->hd, forwarding all internal pointers $366c) 
for (Registerlist regs = roots.registers; regs != NULL; regs = regs->t1l) 
(scan register regs->hd, forwarding all internal pointers $366d) 
/* all pointers in roots have now been forwarded */ 
for (; scanp < hp; scanpt++) 
(scan object *scanp, forwarding all internal pointers $366e) 
3 


Further details are left for Exercise 1 and Appendix N. 


4.5.2 A brief example 


lillustrate copying collection using a heap of size 20. Suppose there are three roots, 
and the heap looks like this: 


Roots: ls a . | 


From-space: 


To-space: 
scanp _4 


hp 
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The reachable S-expressions are all part of one list; two cons cells point to the 
same symbol b: 


Le |e 
La | le le 
le le 
| b | NIL 
The collector begins by forwarding the roots. After the first root is forwarded, 
the heap looks like this: 
Roots: | ° ° ° | 


From-space: 


To-space: 


scanp 
hp 


The first object in from-space has been copied into to-space and replaced with a 
forwarding pointer, which is shown with a dotted line. The root now points to the 
copy, with the pointer passing “behind” from-space so as not to clutter the diagram. 
The copied object, as shown by its thick border, is now gray. (Objects in the top row 
are white.) 


After all three roots have been forwarded, thatis, after the execution of the first 
loop in (copy all reachable objects into to-space 273), the heap looks like this: 


Roots: e e 


From-space: 
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scanp 


hp 


Now the collector starts scanning the gray objects located between scanp and hp. 
Gray objects point to white objects, which in a copying collector means that the 
internal pointers in these objects point back to from-space. 

Scanning the first two gray objects does not change the heap, because these ob- 
jects have no internal pointers. (But once scanp moves past them, the first two gray 
objects are considered black.) Scanning the third gray object (the pair) forwards its 
two internal pointers. The symbol 'a has already been copied into to-space, so for- 
warding the car doesn’t copy any data; it just adjusts a pointer: 


Roots: e e e 


From-space: 


To-space: 


SYM } PAIR) 
b Hele] 


Forwarding the cdr requires copying another pair into to-space, however. After 
this copy, the collector increments scanp, and the newly copied pair is now the 
only gray object—the first three objects in to-space are black. 


Roots: E ° ra - | 


From-space: 


Parr} EF 
a b 


scanp 


To-space: 


hp 


The collector continues copying objects pointed to by *scanp until eventually 
scanp catches up with hp. Now to-space holds only black objects and from-space 
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holds only white objects. From-space can be discarded, and the mutator can re- 
sume execution. Its next allocation requests will be satisfied using the four loca- 
tions recovered in to-space. 


Roots: 


From-space: 


To-space: ae PAIR] PAIR} PAIR 


By using forwarding pointers, the collector has preserved the sharing of the sym- 
bol b by two pairs. The same technique also preserves cycles. 


4.5.3 Prototype of a copying system for psScheme 


Although conceptually more elaborate than a mark-and-sweep system, a copying 
system is easier to build. You'll build one (Exercises 1 to 6) based on the data struc- 
tures and supporting functions described in this section. 

The semispaces fromspace and tospace each have size semispacesize. 


276a. (private declarations for copying collection 276a)= 276b > 
static Value *fromspace, *tospace; // used only at GC time 
static int semispacesize; // # of objects in fromspace or tospace 


The system always allocates from fromspace. The next location available to be 
allocated is at the heap pointer hp, and the end of the available space is marked by 
heaplimit. The number of locations that can be allocated before the next collec- 
tion is heaplimit - hp. 


276b. (private declarations for copying collection 276a) += <1276a 277a> 
static Value *hp, *heaplimit; // used for every allocation 
Allocation 


The allocator tests for heap exhaustion, increments hp, and returns the prior value 
of hp. In real systems, hp is kept in a register and allocloc is inlined. 
276c. (copy.c 276c)= 277b > 
Value* allocloc(void) £ 
if (hp == heaplimit) 
collect(); 

assert(hp < heaplimit); 

(tell the debugging interface that hp is about to be allocated 282f) 

return hp++; 


3 
The assertion can help detect bugs in a heap-growth algorithm. 


Tracing roots 


Just as the mark-and-sweep system has a visiting procedure for each type of poten- 
tial root, the copying system has a scanning procedure for each type of potential 


root. These procedures implement the chunks of the form (scan..., forwarding all 
internal pointers) in chunk 273. 


277A. (private declarations for copying collection 276a) += <1276b 278b> 
static void scanenv (Env env); 

static void scanexp (Exp exp); 

static void scanexplist (Explist es); 

(Frame *fr); 

(UnitTest t); 

(UnitTestlist ts); 


(Value *vp); 


static void scanframe 
static void scantest 
static void scantests 
static void scanloc 


The implementations of the scanning procedures are more complicated than 
they would be ina real system. Ina real system, scanning procedures would simply 
forward internal pointers. In our system, because only Value objects are allocated 
on the heap, scanning procedures forward pointers to Value objects but traverse 
pointers to other types of objects. For example, to scan an environment, the col- 
lector forwards the loc pointer and traverses the t1 pointer (by advancing env). 
277b. (copy.c 276c) += 

static void scanenv(Env env) £ 
for (; env; env = env->tl) 
env->loc = forward(env->loc); 


<1276c 277cD> 


3 


The code that scans an object forwards the pointers of type Value * but tra- 
verses the pointers of types Exp and Env. 


277¢. (copy.c 276c) += <1277b 278a> 
static void scanloc(Value *vp) £ 

switch (vp->alt) £ 

case NIL: 

case BOOLV: 

case NUM: 

case SYM: 
return; 

case PAIR: 
vp->pair.car = forward(vp->pair.car); 
vp->pair.cdr = forward(vp->pair.cdr); 
return; 

case CLOSURE: 
scanexp(vp->closure.lambda.body); 
scanenv(vp->closure.env); 
return; 

case PRIMITIVE: 
return; 

default: 
assert(0); 
return; 


3 
The remaining scanning procedures appear in Section N.1.2. 


Forwarding 


The scanning procedures above closely resemble the visiting procedures used by 
a mark-and sweep collector (Sections 4.4.2 and N.1.1). One difference is that the 
forward operation, as shown in chunk (forward pointer p and return the result 272b), 
never makes a recursive call. 


$4.5 
Copying collection 


277 


collect S377e 
type Env 153a 
type Exp A 
type Explist S309b 
forward 278b 
type Frame 223 
type UnitTest 


A 
type UnitTestlist 

S309b 
type Value <A 
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The complete implementation of forward suffers from one more subtlety, 
which arises because a root can appear on the context stack more than once. For ex- 
ample, an evaluation stack might contain two ENV frames whose environments 
share a Value * pointer associated with the name foldr. When the second such 
frame is scanned, the loc field associated with foldr already points into to-space. 
Such a pointer must not be forwarded. 
278a. (copy.c 276c) += 4277¢ 

static Value* forward(Value *p) £¢ 
if (isinspace(p, tospace)) £ 
/* already in to space; must belong to scanned root */ 
return p; 
3 else ¢ 
assert(isinspace(p, fromspace)); 
(forward pointer p and return the result 272b) 


3 


The isinspace test contributes significantly to garbage-collection time, and inlin- 
ing it results in a measurable improvement. 
278b. (private declarations for copying collection 276a) += <1277a 
static inline bool isinspace(Value *loc, Value *space) £ 
return space <= loc && loc < space + semispacesize; 


3 


static Value *forward(Value *p); 


Heap growth 


In a mark-and-sweep collector, a heap can be enlarged simply by adding more 
pages. In our simple copying system, enlarging the heap is more complicated, be- 
cause semispaces are expected to be contiguous. In general, a contiguous block of 
memory can't be enlarged without moving it, so the semispaces have to be copied. 
A collector can proceed as follows: 


1. Allocate a new, larger, to-space. 

2. Copy the live data from from-space into to-space. 
3. Flip from-space and to-space. 
4 


. Allocate a new, larger, to-space. 


If implemented carelessly, this strategy would copy the live data twice when the 
heap grows. A careful implementation delays the growth of the heap until the next 
collection (Exercise 4). Or the issue can be eliminated entirely by splitting each 
semispace into pages (Exercise 5). 


4.5.4 Performance 


As with the mark-and-sweep system, a performance analysis considers a full 
garbage-collection cycle with N = a — L allocations. I again assume the heap 
is in steady state. 


+ Allocation cost. In a copying system, each allocation takes constant work: 
it tests for heap exhaustion and increments the heap pointer. If the heap 
pointer is kept in a machine register and the allocator is inlined, allocation 


takes just a few instructions, making it very fast indeed. Fast allocation is a 
principal advantage of a copying system. 


For example, a compiler might generate code for cons that is analogous to 
this C code: 


279. (untested sample C code 279) = 
register unsigned *hp; 
unsigned *heaplimit; 


unsigned *cons(unsigned car, unsigned cdr) ~¢ 
if (hp+3 > heaplimit) 
gc(); 
hp[@] = PAIR; 
hp[1] = car; 
hp[2] = cdr; 
hp += 3; 
return hp-3; 
3 


A cons cell is allocated and initialized using just a load, a test, three stores, 
a move, and an add. 


When a system must support objects of varying sizes, a copying allocator 
performs well without any additional data structures or adaptations. Unlike 
a mark-and-sweep allocator, a copying allocator works the same way regard- 
less of how many bytes are requested. It does not need multiple free lists, 
first-fit search, or any other strategy to find a chunk of free memory of an 
appropriate size. It simply tests and increments. 


Collector overhead. A copying garbage collector does work proportional to the 
size of the live data. The work itself is more expensive than for the mark-and- 
sweep system, since the collector must copy objects, not just set mark bits. 
But copying also produces a benefit: it “compacts” the live objects, putting 
them in adjacent locations in memory. Compaction improves the perfor- 
mance of the machine's cache and virtual memory, but more importantly, 
it enables fast allocation. 


Memory overhead. Our copying system pays only two memory overheads: 


- Because one semispace is always empty, a copying system requires at 
least y > 2. The “headroom” needed to get adequate performance 
is much larger than in a mark-and-sweep system. As ¥ gets large, how- 
ever, this difference between copying and mark-and-sweep disappears, 
and the most significant cost is the cost of allocation. 


- Like the mark-and-sweep collector, the copying collector must know 
where to find pointers in heap objects. The knowledge is implied by 
the alt field. 


A copying system has no memory overhead for mark bits. And because our 
system stores the gray objects on the heap itself, in the style of Cheney (1970), 
it requires no stack or work list. 


Pause time. Copying allocation always takes constant time; the only pauses 
are at collections. These pauses take time proportional to the amount of live 
data. 
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fromspace 


276a 


semispacesize 


tospace 
type Value 


276a 
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A 
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4.6 DEBUGGING A COLLECTOR 


A garbage-collected system can exhibit two kinds of faults: 


* The system can fail to recycle an unreachable object. Such a fault is a memory leak. 
A memory leak does not affect correctness, only performance: it makes the 
garbage collector run more often than it should, and it makes the heap grow 
faster than it should. Since we rarely know how often a collector “should” run 
or how fast a heap “should” grow, these symptoms are hard to spot—a slow 
memory leak may go unnoticed for a long time. A memory leak is easiest to 
spot when it makes the heap grow so fast that memory is exhausted. 


* The system can recycle an object that is still reachable. When such an object is 
reused, its contents change. From the perspective of an old pointer to the 
object, the change happens for no reason, at an unpredictable time. Such a 
fault, which could occur if a root is overlooked or if a tracing procedure fails 
to follow a pointer, can be difficult to detect. 


Memory leaks aren't catastrophic. You can detect them with a tool like Valgrind 
or Pin (Section 4.10.2), which instruments the code and looks for “lost” memory. 
If you don’t have such a tool, you might still find a leak by observing that the garbage 
collector is retaining too much live data. To know how much is too much, you might 
rely on regression testing or on careful analysis. Once you’re sure there’s a leak, 
you (or a tool) can examine the heap to find out exactly which objects are not being 
recycled and by what combination of pointers those objects are reachable. 

Premature recycling is harder to detect. It usually occurs because the muta- 
tor has kept a root (a pointer to a heap object) and hasn't told garbage collector. 
You might detect such a problem by means of aggressive assertions, also using a 
tool like Valgrind or Pin—this time to flag reads from or writes to an object that has 
been reclaimed but not yet reused—or by one of the techniques below. That said, 
you probably won't have such problems while working the Exercises, because the 
code that keeps roots up to date has been tested extensively. 


4.6.1 An interface for debugging 


If you need to find memory errors, use my debugging code. As described below, 
it tracks the three states shown in Figure 4.1. 


* Memory that is owned by the operating system shouldn't be touched. Neither 
the collector nor the mutator should read or write it. 


* Memory that is owned by the collector should be read or written only by col- 
lector code. 


* Memory that is owned by the mutator may be read or written freely. The 
collector should read or write it only during a call to allocloc. 


Memory changes ownership by means of the labeled transitions in Figure 4.1 on 
the facing page. Memory is acquired in large blocks using malloc; those blocks are 
released using free. A single object is allocated by calling allocloc; if allocloc 
calls the garbage collector, the collector will reclaim unreachable objects. To en- 
able debugging, each of these transitions should be announced by calling the 
debugging functions declared below. These functions mark collector-owned ob- 


Owned by operating system 


reclaim allocate $4.6 
Debugging a 
Owned by mutator collector 
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Figure 4.1: States of memory 


jects as INVALID, and when Valgrind is available, they get it to enforce these rules: 


* No code should read or write any object owned by the collector. If the col- 
lector mistakenly reclaims a reachable object, then the next time any code 
reads or writes that object, Valgrind will complain. 


+ A newly allocated object must be initialized before it is read. If the mutator 
tries to read a newly allocated object, perhaps through a stale pointer, Val- 
grind will complain. 


The debugging functions are implemented in Section N.2, and their interfaces are 
described below. 

After a block of memory has been acquired (via malloc or calloc) to hold heap 
objects, but before any object has been delivered to the mutator via allocloc, the 
collector should call gc_debug_post_acquire. 
281a. (function prototypes for 4Scheme+ 265c) += (S358) <1265d 281b> 

void gc_debug_post_acquire(Value *mem, unsigned nvalues); 
This function must be used carefully; the copying collector can announce the ac- 
quisition of an entire block at once, but because the mark-and-sweep collector 
wraps each Value in an Mvalue, it must call gc_debug_post_acquire on one ob- 
ject at a time. 

When a block of memory that belongs to the collector is no longer needed and 
is about to be released, the collector should call gc_debug_pre_release just before 
calling free. As with acquisition, the mark-and-sweep collector must release one 
object at a time. 
281b. (function prototypes for zScheme+ 265c) += (S358) <281a 281c¢> 

void gc_debug_pre_release(Value *mem, unsigned nvalues); 

Just before the allocator delivers a heap object to the mutator, it should call 
gc_debug_pre_allocate. 
281c. (function prototypes for 4Scheme+ 265c) += (S358) 4281b 281d> type Value A 

void gc_debug_pre_allocate(Value *mem) ; 

When the garbage collector decides an object is unreachable, it should call 
function gc_debug_post_reclaim. This function should be called after the col- 
lector has finished writing to any part of the object. The function will mark 
the object INVALID, and then it will tell Valgrind to complain about any accesses 
to it. Even without Valgrind, the function can help find bugs; for example, if the 
last cons cell in '(abc) is reclaimed prematurely, you'll see the list turn into 
'(ab . <invalid>), making the fault easy to observe. 
281d. (function prototypes for Scheme+ 265c) += (S358) <281c 282a> 

void gc_debug_post_reclaim(Value *mem) ; 
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To reclaim an entire semispace at once, the copying collector may call function 
gc_debug_post_reclaim_block. When the heap grows, the collector must pass the 
old, smaller size, not the new, larger size. 


282a. (function prototypes for Scheme+ 265c) += (S358) <1281d 282b> 
void gc_debug_post_reclaim_block(Value *mem, unsigned nvalues); 


Whenever the mutator uses a value that is obtained by dereferencing a pointer 
into the heap, it should wrap that value in validate (chunk 225c). If the alt field 
of v is INVALID, validate(v) halts the program with an error message. Otherwise 
it returns v. The evaluator in Chapter 3 calls validate, and your own code should 
also call validate whenever it reads a value that you believe should be good. 

If the tools above aren't enough, use functions gcprint and gcprintf to write 
whatever you like to standard error. Function gcprint works like print, and 
gcprintf works like printf, but they work only when the environment variable 
GCVERBOSE is set. If GCVERBOSE is not set, gcprint and gcprintf do nothing. 


282b. (function prototypes for uScheme+ 265c) += (S358) <282a 282c> 
void gcprint (const char *fmt, ...); /* print GC debugging info */ 
void gcprintf(const char *fmt, ...); 


The debug code is initialized by initallocate in Appendix N, which calls 
gc_debug_init. 
282c. (function prototypes for 4Scheme+ 265c) += (S358) <282b 
void gc_debug_init(void); 
Some of the debugging functions are used in some of the prototype code above: 
282d. (tell the debugging interface that each object on page has been acquired 282d) = (268a) 
- unsigned i; 
for (i = 0; i < sizeof (page->pool)/sizeof(page->pool[0]); i++) 
gc_debug_post_acquire(&page->pool[i].v, 1); 
3 


282e. (tell the debugging interface that &hp->v is about to be allocated 282e)= (268b) 
gc_debug_pre_allocate(&hp->v) ; 


282f. (tell the debugging interface that hp is about to be allocated 282f)= (272b 276c) 
gc_debug_pre_allocate(hp); 


4.6.2 Debugging techniques 


Because garbage collections and allocations can happen at unpredictable times, 
a bug in a garbage collector often appears only intermittently. Worse, it can fail to 
appear until long after the initial fault. Bugs can be found sooner when every read 
and write is monitored by a tool like Valgrind. And you can give Valgrind more 
leverage—or if necessary, debug without Valgrind—by looking for faults early. Try 
these tricks: 


* Trigger a garbage collection before every allocation request. This trick may 
slow your program by many orders of magnitude, but it gives you a chance 
of detecting a missing root as soon as it disappears. 


« After each collection, check that every pointer points to a valid object in the 
right space. 


* After each collection, take a snapshot of the heap and run the collector 
again—once for mark-and-sweep, twice for copying. If the new heap is not 
identical to the snapshot, there is a bug in the collector. (This technique will 
not detect a missing root.) 


To debug a mark-and-sweep collector, try the following: 


+ After marking the live objects, sweep the entire heap, making unmarked ob- 
jects INVALID. 


+ If you are worried about memory corruption in your mark bits, use a whole 
word instead of a single bit. Instead of 0 and 1, use a pair of unusual values 
like O0xdeadbeef and Oxbadface. If you ever see a different value, something 
is stomping on your mark bits. 


To debug a copying collector, try the following: 


* When you “free” old spaces, don’t actually call free. Invalidate them, and let 
validate flag stale pointers to those spaces. 


+ When you copy live data into to-space, use gc_debug_post_reclaim_block 
to make the from-space inaccessible. Then, before the flip, allocate a new 
from-space. If you have mistakenly failed to forward some pointer, the next 
access through that pointer will make Valgrind complain. (If you don’t have 
Valgrind, the next read will find an INVALID value, which will make validate 
complain.) 


4.7 MARK-COMPACT COLLECTION 


The great advantage of copying collection is that by moving live objects into to- 
space, it creates contiguous free space for allocation. Contiguous free space is also 
created by mark-compact collection. Like a mark-sweep collector, a mark-compact 
collector marks live objects, but instead of sweeping reclaimed objects onto a free 
list, it moves the live objects to eliminate the gaps between them, leaving free space 
contiguous. Live objects are often moved using a “sliding” algorithm, which pre- 
serves the order of live objects in memory. This algorithm maintains locality prop- 
erties that can affect the performance of the mutator. 

Mark-compact collection offers the same benefits for allocation as a copying 
collector: fast allocation from a contiguous block of memory. And it takes less 
space. But because it may touch every live object twice—once to mark it and once 
to compact it, it takes more time than either copying or mark-sweep collection. 


4.8 REFERENCE COUNTING 


Tracking roots appears to require support from the compiler or some run-time 
overhead.* If you can’t get support from the compiler and you don’t want to pay 
run-time overhead, you might look for other ideas. Because an object is definitely 
unreachable if there are no references to it, one idea is to reuse an object once it is 
no longer referred to by any other object. 

To make the idea work, a system needs to track not simply whether an object 
is referred to, but how many times. For example, after the following definitions are 
evaluated, the Value object for 'a is referred to twice, from both x and y: 

283. (transcript 258) += 1258 
-> (set x '(a b)) 
-> (set y (car x)) 
If x were reassigned, it would remove a reference to 'a’s object. But deallocating 
'a’s object would be unsafe, because y still points to it. If 'a’s object were deallo- 


41 say “appears to” because the ingenious conservative garbage-collection technique developed by 
Boehm and Weiser (1988) works without either one. 
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cated and then reused to hold a new value, say v, then y’s value would suddenly 
be v, for no obvious reason. 

References are tracked by reserving a field on each object for its reference count. 
An object’s reference count is incremented when a new reference is made to it, and 
the count is decremented when a reference is removed. When its reference count 
becomes zero, the object is eligible to be reused, and it can be placed on a free list. 

Reference counts can require a lot of maintenance. For example, a hypothetical 
pScheme interpreter would maintain reference counts as follows: 


* Whenever an object was bound into to an environment, e.g., to be passed as 
a parameter or let-bound to a local variable, the interpreter would increment 
its reference count. 


* Whena psScheme procedure exited, the interpreter would decrement the ref- 
erence counts of the procedure’s formal parameters—even if the exit were 
caused by a run-time error. 


* When the interpreter left the body of a let expression, it would decrement 
the reference counts of let-bound objects. 


* When the interpreter evaluated a set, it would increment the reference 
count of the newly assigned value, and it would decrement the reference 
count of the previous value of the set variable. 


* When the interpreter allocated a new cell is created, it would increment the 
reference counts of the car and cdr. 


+ When a decrement made the reference count of a cons cell go to zero, the 
interpreter would put the cons cell on a free list. 


* When the interpreter took a cons cell off the free list, it would decrement the 
counts of the car and cdr. 


In short, when pointers are manipulated, reference counts need to be adjusted. 
This adjustment creates complexity in the interpreter and inefficiency in its run 
time. In a reference-counted system, work per assignment can outweigh work per 
allocation. And although reference counting is conceptually simple, it can be ex- 
pensive to retrofit to existing code: any code that moves pointers has to be modified 
to adjust reference counts. 

Although its overhead can be high, a reference-counting system never has to 
pause the mutator for a long time. By delaying the decrement of a car and cdr until 
acons cell is reused, the system can guarantee that every allocation and assignment 
requires at most a constant amount of memory-management work. 

The overhead of reference counting can be reduced by static analysis and other 
tricks, and it can sometimes be offloaded onto a parallel processor or processor 
core. But unlike the overhead in a garbage-collected system, which can be reduced 
by enlarging the heap, the overhead of reference counting cannot easily be ad- 
justed: the cost of each assignment and allocation is independent of the size of the 
heap. Because shrinking the heap does not change the overheads, reference count- 
ing easily outperforms garbage collection when heap space is tightly constrained. 

Reference counting cannot reclaim “cyclic garbage”; in a circular data struc- 
ture, no count ever goes to zero. Circular structures may be created by program- 
mers using set-car! and set-cdr!, but they may also be created simply by allo- 
cating closures. (In a naive implementation of closures, a closure contains an en- 
vironment which contains a binding to a location containing the original closure.) 
Issues with cyclic garbage can be worked around by various clever techniques, but 


these techniques work only in limited domains. Reference counting seems most 
successful in languages that don’t create cycles. 

Reference counting seems to be most effective when it does “double duty,” i.e., 
when the reference counts are used not only to reclaim memory, but also to im- 
plement some other feature. One such feature is timely finalization, which is to 
perform some user-level task when an object is reclaimed. Such tasks may include 
closing open file descriptors or removing windows from a graphical user interface. 
Garbage-collected systems can also provide finalization, but it is not always guar- 
anteed, and it is seldom timely: the time at which a garbage collector reclaims a 
dead object can’t easily be predicted. 

Another feature for which reference counting can be useful is the copy-on-write 
optimization. This optimization applies to computations in which it is unsafe to 
mutate shared objects, so to play it safe, the program has to make a private copy, 
then mutate the copy. But if the reference count says there is only one reference to 
the object, then it isn’t shared, and it can be mutated without making a copy. This 
technique is used in the Newsqueak language to make array updates efficient in the 
common case (Pike 1990). 

Reference counting also shines in distributed systems, where costs of local 
computation are almost irrelevant; what counts is minimizing the number of mes- 
sages sent between machines. If a garbage collector has to follow pointers across 
machine boundaries, that can require a lot of messages. Adjusting reference 
counts also requires messages, but these messages can often be combined with 
the messages used to refer to or assign values, so in terms of message traffic, refer- 
ence counting comes essentially for free. For this reason, distributed architectures 
such as Java's Jini use reference counting. 


4.9 GARBAGE COLLECTION AS IT REALLY IS 


In most garbage-collected systems, the collector relies on a compiler to help it iden- 
tify roots and distinguish pointers from non-pointers. 


* The compiler and collector agree on a calling convention for procedures, so 
the collector can find the activations of all the procedures on the call stack. 
For each source procedure, the compiler provides a map of the stack frame, 
which tells the collector where the roots are, i.e., which machine registers 
and stack variables point to heap objects. A good compiler is sophisticated 
enough to omit dead variables (i.e., variables the compiler knows will not be 
used again) from the stack map. 


The compiler identifies the global variables that point to heap objects. 


The compiler identifies the size and layout of each heap object, so the collec- 
tor will know how big the object is and what parts of it point to other heap 
objects. Most compilers put one or more header words before the heap ob- 
ject. A header word might point to a map that shows where the pointers are 
in the object, or it might point to a snippet of bytecode that the collector can 
interpret to find pointers within the object. 


In some systems, the header simply tells how many words there are in the 
object, and the compiler uses the low bit of each word as a marker to dis- 
tinguish pointers from integers. Such systems are easy to identify, as they 
provide, e.g., only 63 bits of integer precision on a 64-bit machine. 


State-of-the art systems reduce overheads by using concurrent, generational, and 
sometimes parallel garbage collection. 
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* Pause times can be reduced if the collector does just part of its work and 
then yields the processor back to the mutator; such a collector is called incre- 
mental. Or the collector can run concurrently with the mutator, on another 
processor; such a collector is called concurrent. Incremental and concurrent 
techniques can also be combined. In all cases, the shorter pause times are 
paid for by some additional overhead, which is required to synchronize the 
actions of the collector and the mutator. 


+ Elapsed time can be reduced if the collector does some work, like marking 
or copying objects, in parallel on multiple processor cores. Such a collector 
is called parallel. Parallel garbage-collection threads may require synchro- 
nization overhead, but if the relevant processor cores would otherwise be 
idle, net overhead drops. To balance the load among threads, a system may 
copy objects depth-first, using an auxiliary stack, then allow idle garbage- 
collection threads to “steal” work from this stack—a standard technique in 
parallel systems. 


Overall overhead can be reduced by arranging for most garbage collections 
to reclaim a higher percentage of objects. Collectors that do this are usually 
generational. A generational collector divides the heap into two or more gen- 
erations. The youngest generation, or nursery, is where objects are allocated. 
When it fills, itis collected by a minor collection. According to the generational 
hypothesis, most objects die young and so don’t survive a minor collection; the 
rare survivors are promoted into an older generation. Older generations are 
collected rarely, by major collections. 


In a generational system, the nursery is large compared to the number of 
objects that survive a minor collection, and older generations are relatively 
smaller. This arrangement achieves most of the performance benefit of 
large y at a fraction of the memory cost. Some generational systems use 
a hybrid collector; objects are copied out of the nursery, keeping free space 
contiguous, but older generations are collected using mark-and-sweep tech- 
niques. This trick cuts y in half for the older generations. 


Concurrent collection and generational collection involve substantial interac- 
tion with the mutator. If the mutator runs concurrently, or if it mutates objects in 
an old generation, it could violate the collector’s invariant that black objects point 
only to other black objects. 


* The mutator could update a pointer inside a black object, which by definition 
has already been marked live or copied and is not slated to be revisited. 


* During a minor collection, objects in older generations are not traced, so 
they are effectively black objects. If the mutator has updated such an object 
since the previous collection, the invariant may be violated again. 


This issue is resolved by a write barrier. A write barrier forces the mutator to notify 
the collector when it writes a pointer into an object allocated on the heap. When 
the collector learns that a black object has been mutated to contain a pointer to 
a white or gray object, it has a choice: it may follow the new pointer right away, 
making it point to a gray object, or it may recolor the black object gray, scheduling 
it to be traced again before collection completes. 

When notified by a write barrier, the garbage collector saves the location that 
is written to, in a data structure called a remembered set. A remembered set may or 
may not be precise; precision can be expensive. For example, the collector might 
choose to log every pointer that is updated via a write barrier, giving it very precise 


information—but the log may take significant space. Or at another extreme, the 
collector might simply mark a page containing the object written to, costing only 
one bit of space overhead—but it may eventually need to scan the entire page for 
interesting pointers. 

Beyond generational, concurrent, and parallel collection, many other tech- 
niques are available to deploy. 


* Many systems, especially those based on copying collectors, place suffi- 
ciently large objects in separate areas of memory. These large-object areas 
are treated specially, and they are not copied, even by a copying collector. 
A large-object area is especially useful for storing large strings or bitmaps, 
which do not contain pointers and so need not be scanned. Such objects can 
be added to the live data of an advanced system without increasing garbage- 
collection times proportionally. 


* Modern collectors can work even without support from the compiler. The 
mark-and-sweep collector developed by Boehm and Weiser (1988) works 
without any compiler support. It finds roots by examining every word on 
the call stack, plus the program segments that hold initialized and uninitial- 
ized data. It finds pointers by examining every word in every heap-allocated 
object. In both cases, if a word appears to point to a heap-allocated object, 
the collector conservatively assumes that it is a pointer, and therefore that 
the object pointed to is live. (Because it is in cahoots with the allocator, the 
garbage collector knows the addresses of all the heap-allocated objects.) This 
collector has achieved remarkable results with C and C++ programs, some- 
times outperforming malloc and free. 


4.10 SUMMARY 


Automatic memory management recycles unneeded memory so programmers 
don’t have to. Unless they need more live data than the machine can hold, pro- 
grammers can pretend that memory is infinite—they can allocate arbitrarily many 
objects without ever having to free one. 

In a garbage-collected system, the collector and allocator work as a team, and they 
must be analyzed as a team. The metric that should be analyzed is usually work per 
allocation. 

Mark-and-sweep systems perform well when allocation rates are low, so the 
cost of allocation is not a bottleneck. They require just a bit more memory than is 
needed to hold the live data. And with little difficulty, a mark-and-sweep system can 
run legacy code that was written for malloc and free: the user’s free does nothing, 
and the real free is called only by the garbage collector. 

Copying systems provide very fast allocation, but objects in the heap move. 
These properties are related: allocation is fast because free space is contiguous, 
and free space is made contiguous by moving objects. Moving objects, also called 
compaction, also eliminates fragmentation and can improve locality. Copying sys- 
tems perform very well when allocation rates are high, because allocation is so 
fast. But copying requires more memory than mark-and-sweep systems. And 
copying collection requires care to implement; because compaction moves objects, 
the compiler must be aware that objects move, and it must tell the collector exactly 
where to find all the pointers. 

In both copying and mark-and-sweep systems, garbage-collection overhead can 
be reduced by making the heap larger. When there is enough memory to make 7 
large, allocation cost dominates, and copying collection usually wins. 
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The real cost of automatic memory management depends not just on the collec- 
tion technique but on the program. Simple programs that don’t allocate much may 
spend only a few percent of their time in garbage collection. Programs that allocate 
heavily may spend up to 20 percent of their time in garbage collection—more if the 
collector is badly tuned. Garbage collection can be faster than malloc and free, 
even on programs that aren't designed to exploit a garbage collector (Zorn 1993). 
But a garbage-collected system needs more memory, perhaps up to twice as much. 

Allocation is usually perceived as expensive; using cons in Scheme or new 
in Smalltalk costs allocation time, initialization time, and a share of garbage- 
collection time. And reducing allocation can improve performance. But don’t go 
too far. If you replace clean allocation code with code that works by mutating and 
reusing objects, say by using set-car! and set-cdr! to avoid cons, you risk a 
great loss in robustness and reliability in exchange for a small gain in performance. 
Since the 1990s, such tricks have been largely unnecessary. While it is never wise 
to allocate gratuitously, garbage-collected systems perform well enough that pro- 
grammers need not use mutation merely for performance reasons. In fact, muta- 
tion makes some modern generational collectors perform worse than they would 
otherwise. 


4.10.1 Key words and phrases 


ALLOCATION POINTER Ina COPYING COLLECTOR, a pointer to the beginning of the 
contiguous free space. Usually stored in a dedicated machine register. 


AUTOMATIC MEMORY MANAGEMENT A memory-management technique in which 
the HEAP OBJECTS are allocated on a MANAGED HEAP and are recovered and 
reused by a language’s implementation or run-time system. MEMORY SAFETY 
is guaranteed by the system. The most common method is GARBAGE COL- 
LECTION, but REFERENCE COUNTING is sometimes used. Compare EXPLICIT 
MEMORY MANAGEMENT. 


CALL STACK A stack of procedure activations, each of which is something like an 
ENV frame on the evaluation stack of Chapter 3. Each activation may include 
a return address, formal parameters, local variables, and saved registers. 
A call pushes an activation onto the stack; a return pops the stack. 


COMPACTING COLLECTOR A GARBAGE COLLECTOR that moves or copies LIVE OB- 
JECTS into compact, contiguous space, leaving free space also contiguous. 
Making free space contiguous enables fast allocation, and making live ob- 
jects contiguous may improve locality. COPYING COLLECTORS are automat- 
ically compacting collectors. A MARK-AND-SWEEP collector can be made to 
compact by adding a compaction step. 


CONSERVATIVE COLLECTOR A GARBAGE COLLECTOR that works without having 
precise information about where ROOTS are located, where pointers are lo- 
cated inside objects, or both. A conservative MARK-AND-SWEEP COLLECTOR 
developed by Boehm, Weiser, Demers, and others has been widely used un- 
der the name libgc. 


COPYING COLLECTOR A GARBAGE COLLECTOR that traces pointers and copies ev- 
ery LIVE OBJECT to a fresh, empty region of memory. Whatever fresh mem- 
ory is left over is used to satisfy future requests for HEAP ALLOCATION. Un- 
like a MARK-AND-SWEEP collector, a copying collector recovers contiguous 
free space, so allocation can be very efficient. 


DEAD OBJECT A HEAP OBJECT whose value is guaranteed not to affect any future 
computation. Compare LIVE OBJECT. 


DEAD VARIABLE A formal parameter or local variable whose value is guaranteed 
not to affect any future computation. 


EVALUATION STACK In wScheme-, the stack S that holds all the information in a 
CALL STACK, plus additional information about what computation takes place 
after the current expression is evaluated. 


EXPLICIT MEMORY MANAGEMENT A memory-management technique in which the 
HEAP OBJECTS must be recovered and reused by the programmer, using ex- 
plicit primitives to allocate and deallocate objects. MEMORY SAFETY is the 
programmer’s problem. Compare AUTOMATIC MEMORY MANAGEMENT. 


FORWARDING POINTER A value left behind after a HEAP OBJECT has been copied 
by a COPYING COLLECTOR, so that the object won't be copied a second time. 


FREE LIST In a MARK-AND-SWEEP collector, a list of reclaimed objects that can be 
used to satisfy future requests for HEAP ALLOCATION. 


GARBAGE COLLECTION An algorithm that examines the HEAP, finds the LIVE DATA, 
recovers all HEAP OBJECTS that are not live data, and uses their memory to 
satisfy future requests for HEAP ALLOCATION. Garbage collection may be 
done while the rest of the program is stopped, as in this chapter. It may 
be done incrementally, so that garbage collection is interleaved with other 
computation. And it may be done concurrently, with both collector and MuU- 
TATOR doing work at the same time. Typical methods include MARK-AND- 
SWEEP COLLECTION and COPYING COLLECTION. 


GENERATIONAL COLLECTOR A collector that divides HEAP OBJECTS into different 
groups, called generations, according to the number of collections they have 
survived. Objects that have survived more collections are collected less fre- 
quently. 


GENERATIONAL HYPOTHESIS The hypothesis that most objects die young. (In the 
literature, this hypothesis is called the weak generational hypothesis.) 


HEAP Memory area used for objects that may outlive the activation of the function 
that allocates them. In languages with EXPLICIT MEMORY MANAGEMENT, 
the heap is managed by the programmer using primitives like C’s malloc and 
free or C++’s new and delete. “Heap” also means the set of all objects allo- 
cated in the heap, which is modeled by the HEAP GRAPH. 


HEAP ALLOCATION Allocation of an object on the HEAP. 
HEAP OBJECT An object allocated on the HEAP. 
LIVE DATA The set of all LIVE OBJECTS. 


LIVE OBJECT A HEAP OBJECT whose contents might affect a future computation. 
Liveness is an undecidable property, so itis approximated by REACHABILITY: 
an object that is REACHABLE from a ROOT is deemed live. Compare DEAD 
OBJECT. 


MANAGED HEAP AHEAP under the control of AUTOMATIC MEMORY MANAGEMENT, 
in which MEMORY SAFETY is guaranteed. 
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MARK-AND-SWEEP COLLECTOR A GARBAGE COLLECTOR that traces pointers and 
marks every LIVE OBJECT, then reclaims DEAD OBJECTS and uses their space 
to satisfy future requests for HEAP ALLOCATION. Unlike a COPYING COLLEC- 
TOR, it does not move or copy objects. 


MARK BIT A bit used by a MARK-AND-SWEEP COLLECTOR to tell whether a HEAP 
OBJECT is LIVE. May be stored with the object, or if the collector is not par- 
allel, mark bits may be grouped and stored away from their objects, so that 
the hardware cache works better. 


MEMORY SAFETY A property ofa language which guarantees that at all times, every 
pointer points to valid data, every cons cell holds valid data, and so on. 


MUTATOR A program doing useful work, which the GARBAGE COLLECTOR is in- 
tended to serve. So called because it may inconveniently mutate pointers 
inside the objects that the garbage collector is trying to manage. 


REACHABILITY An analysis that finds locations that can be reached by following 
pointers from a ROOT. 


REFERENCE COUNTING A form of AUTOMATIC MEMORY MANAGEMENT in which 
every HEAP OBJECT is associated with a reference count, which tracks the num- 
ber of pointers to the object. When the reference count goes to zero, the 
object can be reclaimed. Useful primarily in specialized situations: when 
memory is nearly exhausted, or when it is difficult or impossible to find or 
follow pointers inside objects, or perhaps most of the overhead can be of- 
floaded to another processor. 


Root A global variable, formal parameter, local variable, or machine register 
whose contents are presumed capable of affecting the outcome of future 
computation. 


STACK ALLOCATION Allocation on the CALL STACK. Used for variables and objects 
that are guaranteed to be DEAD when a function returns. In Impcore and C, 
formal parameters and local variables die on return and so can be allocated 
on the stack. In Scheme, a formal parameter or local variable can live on in 
a closure; if it is not captured in any closure, it can be allocated on the stack. 
Formals and locals that are captured in a closure are usually allocated on the 
HEAP, unless a sophisticated analysis shows that stack allocation is safe. 


TRICOLOR MARKING An abstract model that describes the process of discovering 
live data by following pointers from ROOTS. The model can describe both 
COPYING and MARK-AND-SWEEP COLLECTION. Tricolor marking is especially 
useful for explaining the invariants used by incremental or concurrent col- 
lectors. 


UNREACHABLE Describes an object whose contents cannot be obtained by follow- 
ing pointers from any root. Every unreachable object is DEAD, but not every 
dead object is unreachable. In GARBAGE COLLECTION, however, we approx- 
imate: unreachable objects are considered dead and reachable objects are 
considered LIVE. 


WORK PER ALLOCATION A suitable measure of the cost of a MANAGED HEAP. 


4.10.2 Further reading 


Wilson (1992) surveys well-established garbage-collection techniques for single- 
processor machines; although dated, the survey is excellent and is easy to obtain. 
Jones, Hosking, and Moss (2011) survey more recent techniques; for a gentler in- 
troduction, see Jones and Lins (1996). All have extensive lists of references. 

If you are interested in original work, McCarthy (1960) outlines the mark-and- 
sweep method, and Minsky (1963) describes a compacting collector that copies live 
data to tape, then back into main memory. Minsky points out that copying has 
the added benefits of linearizing cdr chains and compacting both the entire heap 
and individual objects (like lists). Fenichel and Yochelson (1969) describe copying 
collection that uses only machine memory, without any external storage; Cheney 
(1970) shows how to use to-space as a queue of gray objects. Baker (1978) describes 
a variant that collects garbage without stopping the computation. Dijkstra et al. 
(1978) analyze concurrent garbage collection; they introduce the term “mutator” 
and the tricolor abstraction. Lieberman and Hewitt (1983) describe real-time col- 
lection, and Ungar (1984) introduces generational collection. 

Boehm and Weiser (1988) introduce a conservative collector; Boehm and his col- 
leagues developed this collector into a sophisticated component that can easily be 
added to almost any C program. Zorn (1993) reports on experiments with Boehm’s 
collector, adding garbage collection to programs written for manual memory man- 
agement. Even without compiler support, garbage collection is competitive with 
malloc and free, and sometimes faster. Bartlett (1988) shows how conservative 
techniques can be used even in a copying system. Smith and Morrisett (1999) com- 
pare the two styles of conservative collection. 

Hertz and Berger (2005) describe an experiment that explores whether and how 
perfect manual memory management can outperform garbage collection. A pro- 
gram written for garbage collection is run with instrumentation that records when 
every object becomes unreachable. Calls to free are then inserted into the pro- 
gram at exactly the right places, and the program is re-run with malloc and free. 
The resulting perfect manual management can be matched by a garbage collector, 
but at the cost of five times as much memory. Blackburn, Cheng, and McKinley 
(2004) use other experiments to elucidate connections between design choices and 
performance. 

Heap growth is a subtle topic that I cannot do justice to, but a good place to start 
is with the “ergonomic” algorithm of Vengerov (2009). 

Mature garbage collectors support parallel and concurrent collection. Marlow 
et al. (2008) describe a page-based copying collector that runs in parallel on multi- 
ple CPU cores. 

The performance of reference counting can be improved by many tricks, most 
of which involve allowing reference counts to get out of data temporarily, to be 
implied by other information (like the program counter), or both. Deutsch and 
Bobrow (1976) describe an influential early system. Bacon et al. (2001) describe an 
aggressive, parallel, purely reference-counting system that achieves pause times 
measured in milliseconds (on year 2000 hardware!). 

Tools like Valgrind have revolutionized the detection of memory errors, includ- 
ing errors in garbage collectors. Nethercote and Seward (2007a,b) describe Val- 
grind’s memory-checking tool and overall instrumentation framework. Luk et al. 
(2005) describe Pin, a similar tool that is less widely deployed but often faster than 
Valgrind. 
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Table 4.2: Synopsis of all the exercises, with most relevant sections 


Exercises Section Notes 

1 4.5 Complete the copying collector. 

2 to 6 4.5 Measure, analyze, or extend your completed copying col- 
lector. 

7and8 4.4 Complete the mark-and-sweep collector. 

9to1l 4.4 Measure, analyze, or extend your completed mark-and- 
sweep collector. 

12 4.4 Prove that lazy sweeping works. 

13 4.5 Analyze costs of copying collection. 

14to16 4.4 Analyze costs of mark-and-sweep collection. 


17to19 4.40r4.5 Experimental study of object lifetimes. Requires a collec- 
tor. 


All exercises require Sections 4.1 to 4.3. 


As I write, tools for analyzing and understanding the performance of managed 
heaps are not widely deployed. Runciman and Wakeling (1993) describe one of the 
first experiments with “heap profiling.” Serrano and Boehm (2000) describe other 
tools used to understand the performance of a managed heap. 


4.11 EXERCISES 


The exercises are summarized in Table 4.2. As highlights, I recommend that you 
undertake these exercises: 


Build a copying collector (Exercise 1). 


* Instrument your collector to gather statistics, and measure work per alloca- 
tion as a function of the ratio of heap size to live data (Exercises 2 and 3). 


* Derive a formula for the amount of work per allocation involved in copying 
collection, again as a function of the ratio of heap size to live data. Then 
compare the results from your measurements with the results predicted by 
your formula (Exercise 13). Once you understand the algorithms, you can 
predict costs very accurately. 


* Do it all again for the mark-and-sweep collector (Exercises 7 and 14). 


The copying collector is a little easier to build, and the mark-and-sweep collector 
is a little easier to analyze. 


4.11.1 Retrieval practice and other short questions 

A. After the expression (set xs (cdr xs)) is evaluated, what object or objects are 
likely to become garbage, and why? 
Conceptually, what is a root? 
What are the three categories of root? 


What is the mutator? 


E. Copying an object seems like it would always be more expensive than marking. 
But the copying collector has a compensating performance benefit. What is it? 


F. Ifa managed heap is just barely larger than the amount of live data, what goes 
wrong? 


G. If all the objects we are trying to reclaim have type Value, what is the point in 
looking at objects of type Env? 


H. The mark phase is complete and an object is unmarked. What color is it: black, 
white, or gray? 


I. The mark phase is complete and an object is marked. What color is it: black, 
white, or gray? 


J. The mark phase is in progress, and an object is marked. What two colors might 
it be? 


K. In copying collection, what is a forwarding pointer? 


L. During copying collection, an object has been copied into to-space, but objects 
that it points to are still in from-space. What color is it: black, white, or gray? 


M. During copying collection, what color are the objects in from-space? 


4.11.2 Build, measure, and extend the copying collector 


The first four exercises are cumulative; each builds on the ones before it. The last 
two exercises build on just the first. 


1. Complete the copying garbage collector. 


(a) Write a copy procedure that copies all live objects into to-space and 
leaves hp and heaplimit pointing to appropriate locations in to-space. 


(b) Write a function collect to be called from allocloc in chunk 276c. 
This function should call copy, flip the semispaces, and possibly en- 
large the heap. 


2. Gather statistics. Instrument your collector to gather statistics about memory 
usage and live data in the ~Scheme heap. 


(a) During every collection, record the number of live objects copied. Af- 
ter the collection, have your copy procedure print the total number of 
locations on the psScheme heap (the heap size), the number that hold 
live objects at the given collection (the live data), and the ratio of the 
heap size to live data. 


(b) Gather and print statistics about total memory usage: after every 10th 
garbage collection, and also when your interpreter exits, print the total 
number of cells allocated and the current size of the heap. This infor- 
mation will give you a feel for the power of reuse; with garbage collec- 
tion, some of the programs in this book can run in 60 times less memory 
than without garbage collection. 


(c) When your interpreter exits, print the total number of collections and 
the number of objects copied during those collections. 


3. Implement a y-based policy for heap growth. The performance of a garbage col- 
lector is affected by the size of the heap, which should be controllable by the 
programmer. My function gammadesired, which is defined in chunk $369a, 
makes it possible to use the jsScheme variable &gamma-desired to control the 
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size of the heap. Because piScheme doesn’t have floating-point support, the 
integer &gamma-desired represents 100 times the desired ratio of heap size to 
live data. Using gammadesired, modify collect so that after each collection 


it enlarges the heap until the actual + is at least zag &gamma-desired. 


(a) Measure the amount of work done by the collector for different values of 
&gamma—desired and for different programs. Think carefully about the 
units in which work is measured. 


(b) Plot a graph that shows collector work per allocation as a function of the 
value of &&amma-desired. 


(c) Using your measurements from part (a), choose a sensible default 
value for y. Use that default when the wScheme code has not set 
&gamma-desired. 


Remember that 7 is the ratio of the total heap size to the amount of live data, 
not the ratio of the size of a semi-space to the amount of live data. 


. Reduce total work by delaying heap growth. Enlarging the heap immediately af- 


ter a copy operation requires a second copy operation to get the live data into 
the new heap. This second copy costs work without recovering new mem- 
ory; itis pure overhead. Change collect so that if the heap needs to be en- 
larged, it delays the job until just before the next collection. Measure the dif- 
ference in GC work per allocation for both short-running and long-running 
programs. 


. Implement copying collection with non-contiguous semispaces. A heap can be 


grown with less overhead if each semispace is represented as a list of pages. 
A whole semispace is no longer contiguous, but within the semispace, each 
page is contiguous. Allocating from a contiguous page costs the same as al- 
locating from a contiguous semispace, and when the allocator exhausts one 
empty page, it moves to the next. Over an entire garbage-collection cycle, 
allocation incurs only a small additional overhead per page. As long as there 
are enough objects per page, that overhead won't be noticed. 


(a) Modify your copying collector to represent each semispace as a linked 
list of pages. 


(b) Implement a heap-growth algorithm that simply adds pages to both 
semispaces, without copying. 


You can read more about such a system in the paper by Marlow et al. (2008). 


. Implement a simple generational collector. Appel (1989) describes generational 


collection in a very clear, simple setting. Using his technique, modify your 
copying collector so it uses two generations. Measure work per allocation as 
a function of +. 


4.11.3 Build, measure, and extend the mark-and-sweep collector 


The first four exercises are cumulative; each builds on the ones before it. 


7. Implement a mark procedure. Write a procedure mark that implements the 


mark phase of a mark-and-sweep garbage collector. At each collection, tra- 
verse the root set and mark each reachable Mvalue as live. Use the visiting 
procedures in Sections 4.4.2 and N.1.1. Your mark procedure should call the 
appropriate visiting procedure for each of the roots. 


8. Implement a mark-and-sweep allocator. Create an allocator that, together with 
your mark procedure from Exercise 9, forms a complete mark-and-sweep sys- 
tem. 


* The allocator must implement not only allocation but also the unmark 
and sweep phases of collection. It will sweep through the heap from the 
first page to the last page. Instead of just taking the location pointed to 
by hp, as in chunk 268b, the allocator must check to see if the location 


is marked live. If marked, it was live at the last collection, so it cannot $4.11 
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When the allocator finds an unmarked object, it sweeps past the object 
and returns it to satisfy the allocation request, just as in chunk 268b. 
If the allocator reaches the end of the heap without finding an un- 
marked object, it calls mark. 


* In the new system, end-of-page is not the same as end-of-heap. For 
example, after some allocation requests, the heap might look like this: 


pagelist curpage 


eo e]|_>| 


hp 
heaplimit 


White areas, to the left of the heap pointer, have been used to satisfy 
previous allocation requests. Areas marked with gray diamonds, to the 
right of the heap pointer, are potentially available to satisfy future allo- 
cation requests.° When hp reaches heaplimit, the allocator must look 
at the next page; modify the code in chunk 268b to make it so. Only 
after there are no more pages may the allocator call mark. 


« After your allocator calls mark, have it call makecurrent(pagelist), 
which will reset hp, heaplimit, and curpage to point into the first page. 


* The allocator now guarantees that when mark is called, the entire heap 
is unmarked (Exercise 12). But mark cannot guarantee to recover any- 
thing; every cell on the heap might be live. The allocator may have to 
enlarge the heap by adding a new page. Write a procedure growheap 
for this purpose. 


You may find it helpful to split alloc1loc into two functions: one that attempts 
to allocate without calling mark, but sometimes fails, and another that may 
call the first function, mark, and growheap. 


You will have an easier time with your implementation if you work Exer- 
cise 12 first—a thorough understanding of the invariants makes the imple- 
mentation relatively easy. 


9. Gather statistics. After completing Exercise 7, instrument your collector to 
gather statistics about memory usage and live data in the zScheme heap. 
(The pScheme heap, i.e., the collection of all pages, is not the C heap. The 
pScheme heap is managed with allocloc and mark; the C heap is managed 
with malloc and free.) 


(a) During every collection, record the number of objects marked. After 
the collection, have your mark procedure print the total number of lo- 


5They are only “potentially” available because if they are marked, they were live at the last collection 
and must be assumed to be live now. The allocator must unmark and skip over such cells. 
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(b) 


(c) 


cations on the Scheme heap (the heap size), the number that hold live 
objects at the given collection (the live data), and the ratio of the heap 
size to live data. 


Gather and print statistics about total memory usage: after every 10th 
garbage collection, and also when your interpreter exits, print the total 
number of cells allocated and the current size of the heap. This infor- 
mation will give you a feel for the power of reuse; with garbage collec- 
tion, some of the programs in this book can runin 60 times less memory 
than without garbage collection. 


When your interpreter exits, print the total number of collections and 
the number of objects marked during those collections. 


10. Implement a y-based policy for heap growth. The performance of a garbage col- 
lector is affected by the size of the heap, which should be controllable by the 
programmer. My function gammadesired, which is defined in chunk S369a, 
makes it possible to use the «Scheme variable &gamma-desired to control the 
size of the heap. Because jsScheme doesn’t have floating-point support, the 
integer &gamma-desired represents 100 times the desired ratio of heap size 
to live data. 


(a) 


(b) 


(c) 


(d) 


Modify your collector so that after each collection it enlarges the heap, 
possibly by adding more than one page, until the measured 7¥ is as close 
as possible to zag &gamma-desired, without going under. For example, 
executing (set &gamma-desired 175) should cause your collector to in- 
crease the heap size to make + about 1.75. (If y is too big, do not try to 
make the heap smaller; see Exercise 15.) 


Measure the amount of work done by the collector for different values of 
&gamma—desired and for different programs. Think carefully about the 
units in which work is measured. 


Plot a graph that shows collector work per allocation as a function of the 
value of &&amma-desired. 


Using your measurements from part (b), choose a sensible default 
value for y. Use that default when the wScheme code has not set 
&gamma-desired. 


11. Placement of mark bits. Our system puts mark bits in the object headers even 
though there’s no spare bit and we therefore have to allocate an extra word 
per object. 


(a) 


(b) 


(c) 


Rewrite the allocator and collector to pack the mark bits into one or 
more words in the page. You will need to be able to map the address 
of an object to the address of the page containing that object. If you 
arrange for the addresses of pages to fall on k-bit boundaries, where 
GROWTH_UNIT < 2*, you can find the address of the page simply by 
masking out the least significant /; bits of the address of the object. 


Using the new representation, how many more objects can fit into an 
page of the same size? What does this result imply about choosing yy? 


Will this representation work well for a parallel collector? Why or why 
not? 


12. Correctness of lazy sweeping. Prove that in the scheme outlined in Exercise 8, 
mark is called only when no S-expression is marked live. 


(a) 


(b) 


(c) 
(d) 


Find an invariant for the current page pointed to by curpage. When 
&curpage->pool[i] < hp, you'll need a property for curpage->pool[i]; 
when &curpage->pool[i] >= hp, you'll need a different property. Your 
growheap procedure will have to establish the invariant for every new 
page. 

Extend the invariant to include pages before and after curpage. The 
invariants for these two kinds of pages should look an awful lot like 
the invariants for curpage->pool[i] where &curpage->pool[i] < hp 
and &curpage->pool[i] >= hp. Together, these invariants describe the 
white and gray-diamond areas in the picture of the heap. 


Show that growheap, allocloc, and mark all maintain this invariant. 


Show that conditions when mark is called, together with the invariant, 
imply that mark is called only when no S-expression is marked live. 


4.11.4 Analyze costs of collection 


13. Cost of copying collection as a function of y. Even a simple analysis can enable 
you to predict the cost of garbage collection. 


(a) 


(b) 


Derive a formula to express the cost of copying garbage collection as a 
function of y. Measure cost in units of GC work per allocation. Assume a 
fixed percentage of whatever is allocated becomes garbage by the next 
collection. 

You needn't assume that you know anything else about the heap be- 
sides y. 


If you have done Exercise 3, discuss how your formula compares with 
your measurements. Explain any inconsistencies. 


14. Cost of mark-and-sweep collection as a function of y. 


(a) 


(b) 


Derive a formula to express the cost of mark-and-sweep garbage collec- 
tion as a function of 7. Measure cost in units of GC work per allocation— 
in amark-and-sweep system, this cost is often called the mark/cons ratio. 
Assume a fixed percentage of whatever is allocated becomes garbage by 
the next collection. 

You needn't assume that you know anything else about the heap be- 
sides y. 

If you have done Exercise 10, discuss how your formula compares with 
your measurements. Explain any inconsistencies. 


15. Probability of an empty page. Because objects in our mark-and-sweep collector 
don’t move, it can shrink the heap only if it finds a completely empty page. 
Assume that y = 10, so the heap is 90% empty, and that GROWTH_UNIT is cho- 
sen so that one page just fits on a virtual-memory page (about 4KB to 8KB). 
Assuming that objects die independently of their locations, what is the prob- 
ability that an page chosen at random has no live objects in it and can be 
removed from the heap? (The assumption is not borne out in practice—real 
objects tend to die in clumps.) 
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Expected number of cells swept in an allocation. The mark-and-sweep allocator 

skips marked cells until it finds an unmarked cell. Assume that the marked 

cells are distributed independently, so that the probability of any particular 
1 


cell being marked is 5 (Just as in the previous problem, this assumption is 


not borne out in practice.) 


(a) Derive a formula giving, as a function of y, the expected number of 
marked cells the allocator must skip before finding an unmarked cell. 
Calculate this number for some interesting values of 7, e.g., 1, 1.1, 1.2, 
1.5, 2,3, and 5. 


(b) Derive a formula giving, as a function of 7, the probability that the al- 
locator skips at most 3 cells. Calculate this probability for some inter- 
esting values of y. 


4.11.5 Deeper experimental study 


17. 


18. 


Distribution of objects’ lifetimes. Pick a collector and measure the distributions 
of objects’ lifetimes for several programs. Measure lifetimes in units of num- 
ber of objects allocated. You will need to add a field to each object that tells 
when it was allocated, and at each collection you will be able to estimate the 
lifetimes of the objects that died at that collection. The fewer objects that are 
allocated between collections, the more accurate your estimate will be. 


(a) For several programs, approximately what is the distribution of objects’ 
lifetimes? 


(b) Does the distribution of lifetimes depend on -y? Why or why not? 


(c) Does the distribution of lifetimes tell you anything about the genera- 
tional hypothesis? If so, what? 


Measuring space lost to drag. An object may becomes unreachable only some 
times after it is last used. This time, called the drag time of the object, 
contributes to excess space usage in garbage-collected systems. Drag time 
should be measured in units of number of objects allocated. Measure drag 
times in your own system: 


(a) Keep count of the total number of objects ever allocated. This count 
will act as a clock. 


(b) Add a field to each object that tells when it was last used. Every time 
an object is used, its field should be set to the current time. An object 
might be considered “used” when it is looked up in an environment or 
is obtained by a car or cdr operation. 


(c) Add another field to each object that tells when it was last known to be 
reachable. This field can be updated by the garbage collector, or for 
more accurate measurements, you can create a checking function that 
will run more frequently and will update the fields. Such a checking 
function would look a lot like mark. 


(d) When an unreachable object is garbage-collected, log the two times 
(time of last use and time of unreachability) to a file. When the pro- 
gram ends, log the same information for the remaining objects. 


(e) Write a program to read the log and compute two curves. The in-use 
curve records the number of objects in use as a function of time. The 
reachable curve records the number of objects that are reachable, also 
as a function of time. 


(f) The area under each curve is a good measure of space usage. The ratio 
of in-use space to reachable space can measure the degree to which 
reachability overestimates the lifetimes of objects. Compute this ratio 
for several executions of several programs. 


19. Measuring performance costs of overaggressive closures. My implementation of 
lambda captures the entire current environment, including all live variables. 
As long as the closure is live, those variables and all the heap objects they 


point to, transitively, are live. But the only variables a closure really needs $4. ag 
are the ones that appear free in the body of its lambda. The other variables Exercises 
may unnecessarily cause objects to be retained. 299 


(a) Re-implement lambda to build a new environment containing only the 
variables that are actually needed. You might use function freevars 
from Appendix L. 


(b) Measure how this change affects the performance of the garbage- 
collected heap. You might measure the number of collections, equi- 
librium heap size, average lifetime of objects, or drag time. Drag time 
is probably the most interesting measure, since my implementation 
“drags” these unneeded variables along for the ride. 
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Interlude: Scheme in ML 


STUDENT: You and Chris have spent ten years working on 
your compiler, and now you have this highly 
polished literate program, published as a book. 
What did you learn? 


HANSON: Cis a lousy language to write a compiler in. 


Conversation with David R. Hanson, coauthor of 
A Retargetable C Compiler: Design and Implementation 
(Fraser and Hanson 1995). 


The interpreters in Chapters 1 to 4 are written in C, which has much to recom- 
mend it: Cis relatively small and simple; it is widely known and widely supported; 
its perspicuous cost model makes it is easy to discover what is happening at the ma- 
chine level; and it provides pointer arithmetic, which makes it a fine language in 
which to write a garbage collector. But for implementing more complicated or am- 
bitious languages, C is less than ideal. In this and succeeding chapters, I therefore 
present interpreters written in the functional language Standard ML. 

Standard ML is particularly well suited to symbolic computing, especially func- 
tions that operate on abstract-syntax trees; some advantages are detailed in the 
sidebar on the next page. And an ML program can illustrate connections be- 
tween language design, formal semantics, and implementations more clearly than 
aC program can. Infrastructure suitable for writing interpreters in ML is presented 
in this chapter and in Appendices H and I. That infrastructure is introduced by us- 
ing it to implement a language that is now familiar: Scheme. 

The Scheme interpreter in this chapter is structured in the same way as the 
interpreter in Chapter 2. Like that interpreter, ithas environments, abstract syntax, 
primitives, an evaluator for expressions, and an evaluator for definitions. Many 
details are as similar as I can make them, but many are not: I want the interpreters 
to look similar, but even more, I want my ML code to look like ML and my C code 
to look like C. 

The ML code will be easier to read if you know my programming conventions. 


* My naming conventions are the ones recommended by the SML’97 Stan- 
dard Basis Library (Gansner and Reppy 2002). Names of types are written 
in lowercase letters with words separated by underscores, like exp, def, or 
unit_test. Names of functions and variables begin with lowercase letters, 
like eval or evaldef, but long names may be written in “camel case” with 
a mix of uppercase and lowercase letters, like processTests instead of the 
C-style process_tests. (Rarely, I may use an underscore in the name of a 
local variable.) 
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Helpful properties of the ML family of languages 


ML is safe: there are no unchecked run-time errors, which means there are 
no faults that are entirely up to the programmer to avoid. 

Like Scheme, ML is naturally polymorphic. Polymorphism simplifies every- 
thing. For example, unlike the C code in Chapters 1 to 4, the ML code in 
Chapters 5 to 10 uses just one representation of lists and one length function. 
As another example, where the C code in Appendix F defines three different 
types of streams, each with its own get function, the ML code in Appendix H 
defines one type of stream and one streamGet function. And when a job is 
done by just one polymorphic function, not a group of similar functions, you 
know that the one function always does the same thing. 

Unlike Scheme, ML uses a static type system, and this system guarantees that 
data structures are internally consistent. For example, if one element of a list 
is a function, every element of that list is a function. This happens without 
requiring variable declarations or type annotations to be written in the code. 
If talk of polymorphism mystifies you, don’t worry; polymorphism in pro- 
gramming languages is an important topic in its own right. Polymorphism 
is formally introduced and defined in Chapter 6, and the algorithms that 
ML uses to provide polymorphism without type annotations are described 
in Chapter 7. 

Like Scheme, ML provides first-class, nested functions, and its initial basis 
contains useful higher-order functions. These functions help simplify and 
clarify code. For example, they can eliminate the special-purpose functions 
that the C code uses to run a list of unit tests from back to front; the ML code 
just uses foldr. 


To detect and signal errors, ML provides exception handlers and exceptions, 
which are more flexible and easier to use then C’s set jmp and longjmp. 
Finally, least familiar but most important, ML provides native support for al- 
gebraic data types, which I use to represent both abstract syntax and values. 
These types provide value constructors like the IFX or APPLY used in previous 
chapters, but instead of switch statements, ML provides pattern matching. 
Pattern matching enables ML programmers to write function definitions that 
look like algebraic laws; such definitions are easier to follow than C code. 
The technique is demonstrated in the definition of function valueString 
on page 307. For a deeper dive into algebraic data types, jump ahead to Chap- 
ter 8 and read through Section 8.1. 


Names of exceptions are capitalized, like NotFound or RuntimeError, and 
they use camel case. Names of value constructors, which identify alternatives 
in algebraic data types, are written in all capitals, possibly with underscores, 
like IFX, APPLY, or CHECK_EXPECT—just like enumeration literals in C. 


* If you happen to be a seasoned ML programmer, you'll notice something 
missing: the interpreter is not decomposed into modules. Modules get a 
book chapter of their own (Chapter 9), but compared to what’s in Chap- 
ter 9, Standard ML's module system is complicated and hard to understand. 
To avoid explaining it, I define no modules—although I do use “dot notation” 
to select functions that are defined in Standard ML's predefined modules. 
By avoiding module definitions, I enable you to digest this chapter even if 
your only previous functional-programming experience is with uScheme. 


Because I don’t use ML modules, I cannot easily write interfaces or distin- 
guish them from implementations. Instead, I use a literate-programming 
trick: I put the types of functions and values, which is mostly what ML in- 
terfaces describe, in boxes preceding the implementations. These types are 
checked by the ML compiler, and the trick makes it possible to present a 
function's interface just before its implementation. 


My code is also affected by two limitations of ML: ML is persnickety about the 
order in which definitions appear, and it has miserable support for mutually recur- 
sive data definitions. These limitations arise because unlike C, which has syntactic 
forms for both declarations and definitions, ML has only definition forms. 

In C, as long as declarations precede definitions, you can be careless about the 
order in which both appear. Declare all your structures (probably in typedefs) in 
any order you like, and you can define them in just about any order you like. Then 
declare all your functions in any order you like, and you can define them in any 
order you like—even if your data structures and functions are mutually recursive. 
Of course there are drawbacks: not all variables are guaranteed to be initialized, 
and global variables can be initialized only in limited ways. And you can easily 
define mutually recursive data structures that allow you to chase pointers forever. 

In ML, there are no declarations, and you may write a definition only after the 
definitions of the things it refers to. Of course there are benefits: every definition 
initializes its name, and initialization may use any valid expression, including let 
expressions, which in ML can contain nested definitions. And unless your code 
assigns to mutable reference cells, you cannot define circular data structures that 
allow you to chase pointers forever. As a consequence, unless a structurally re- 
cursive function fetches the contents of mutable reference cells, it is guaranteed 
to terminate. ML’s designers thought this guarantee was more important than the 
convenience of writing data definitions in many orders. (And to be fair, using ML 
modules makes it relatively convenient to get things in the right order.) 

What about mutually recursive data? Suppose for example, that type exp refers 
to value and type value refers to exp? Mutually recursive definitions like exp and 
value must be written together, adjacent in the source code, connected with the 
keyword and. (You won't see and often, but when you do, please remember this: 
it means mutual recursion, never a Boolean operation.) 

Mutually recursive function definitions provide more options: they can be 
joined with and, but it is usually more convenient and more idiomatic to nest one 
inside the other using a let binding. You would use and only when both mutually 
recursive functions need to be called by some third, client function. When I use 
mutual recursion, I identify the technique I use. Now, on to the code! 


5.1 NAMES AND ENVIRONMENTS, WITH INTRODUCTION TO ML 


In my C code, Name is an abstract type, and by design, two values of type Name can 

be compared using C’s built-in == operator. In my ML code, because ML strings 

are immutable and can be meaningfully compared using ML’s built-in = operator, 

names are represented as strings. 

303. (support for names and environments 303)= (S213a) 304> 
type name = string 

ML's type syntax is like C’s typedef; it defines a type by type abbreviation. 

Each psScheme name is bound to a location that contains a value. In C, sucha 
location is represented by a pointer of C type Value *. In ML, such a pointer has 
type value ref. Like a C pointer, an ML ref can be read from and written to, but 
unlike a C pointer, it can’t be added to or subtracted from. 


$5.1 
Names and 
environments, 
with introduction 
to ML 
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Table 5.1: Correspondence between jiScheme semantics and ML code 


Semantics Concept Interpreter 
d Definition def (page 307) 
e€ Expression exp (page 306) 
x Name name (page 303) 
v Value value (page 306) 
£ Location value ref (ref is built into ML) 
p Environment value ref env (page 304) 
o Store Machine memory (the ML heap) 
(e, p,7) |) (uv, a") Expression eval(e, p) = 0, 
evaluation with o updated to o’ (page 309) 
(d,p,0) > (p',o’) Definition evaldef(d, p) = (p’,s), 
evaluation with o updated to o’ (page 311) 
xz € domp Definedness find (x, ) terminates without 
raising an exception (page 305) 
p(x) Location lookup find (x, p) (page 305) 
a(p(x)) Value lookup !(find (x, p)) (page 305) 
p{x + e} Binding bind (2, £, p) (page 305) 
a{l+> v}, Allocation call ref v; the result is £ 
where £ ¢ domo 
af{l++ v}, Store update Li=0u 


where £ € domo 


In C, the code that looks up or binds a name has to know what kind of thing a 
name stands for; that’s why the Impcore interpreter uses one set of environment 
functions for value environments € and p and another set for a function environ- 
ment ¢. In ML, the code that looks up or binds a name is independent of what 
a name stands for; it is naturally polymorphic. One set of polymorphic functions 
suffices to implement environments that hold locations, values, or types. 

ML has a static type system, and polymorphism is reflected in the types. An en- 
vironment has type 'a env; such an environment binds each name in its domain 
to a value of type 'a. The 'a is called a type parameter or type variable; it stands for 
an unknown type. (Type parameters are explained in detail in Section 6.6, where 
they have an entire language devoted to them.) Type 'a env, like any type that takes 
a type parameter, can be instantiated at any type; instantiation substitutes a known 
type for every occurrence of 'a. jsScheme’s environment binds each name to a mu- 
table location, and it is obtained by instantiating type 'a env using 'a = value ref; 
the resulting type is value ref env. 

My environments are implemented using ML’s native support for lists and pairs. 
Although my C code represents an environment as a pair of lists, in ML, it’s easier 
and simpler to use a list of pairs. The type of the list is (name * 'a) list; the type 
of a single pair is name * 'a. A pair is created by an ML expression of the form 
(€1, €2); this pair contains the value of e; and the value of e2. The pair (€1, €2) 
has type name * 'a if e, has type name and €2 has type 'a. 
304. (support for names and environments 303) += 

type 'a env = (name * 'a) list 


(S213a) 303 305a> 


The representation guarantees that there is an 'a for every name. 


The empty environment is represented by the empty list. In ML, that’s written 
using square brackets. The val form is like wScheme’s val form. 


305a. (support for names and environments 303) += (S213a) 1304 305b> 
val emptyEnv = [] emptyEnv : 'a env 
(The phrase in the box is like a declaration that could appear in an interface to an $5.1 
ML module; through some Noweb hackery, it is checked by the ML compiler.) Names and 
A name is looked up by function find, which is closely related to the find from environments, 
Chapter 2: it returns whatever is in the environment, which has type 'a. Ifthe with introduction 
name is unbound, find raises an exception. Raising an exception is a lot like the to ML 


throw operator in Chapter 3; it is roughly analogous to longjmp. The exceptions 


I use are listed in Table 5.2 on the following page. a 
305b. (support for names and environments 303) += (S213a) <1305a 305¢> 
exception NotFound of name find : name * 'a env -> 'a 


fun find (name, []) = raise NotFound name 
| find (name, (x, v)::tail) = if name = x then v else find (name, tail) 
The fun definition form is ML’s analog to define, but unlike zScheme’s define, 
it uses multiple clauses with pattern matching. Each clause is like an algebraic law. 
The first clause says that calling find with an empty environment raises an excep- 
tion; the second clause handles a nonempty environment. The infix :: is ML’s way 
of writing cons, and it is pronounced “cons.” 
To check x € dom p, the ML code uses function isbound. 
305¢. (support for names and environments 303) += (S213a) <305b 305d> 
fun isbound (name, []) = false 
| isbound (name, (x, v)::tail) = name = x orelse isbound (name, tail) 
Again using ::, function bind adds a new binding to an existing environment. 
Unlike Chapter 2’s bind, it does not allocate a mutable reference cell. 


305d. (support for names and environments 303) += (S213a) <305c 305e> 
fun bind (name, v, rho) = bind : name * 'a * 'a env -> 'a env 
(name, v) :: rho 


Even though an 'a env isa list of pairs, functions that operate on two lists, like 
those in Chapters 1 and 2, are still useful. Function bindList adds a sequence of 
bindings to an environment; it is used to implement uScheme’s let and lambda. 
If the lists aren't the same length, it raises another exception. Function bindList 
resembles Chapter 2’s bindalloclist, but it does not allocate. Related function 
mkEnv manufactures a new environment given just a list of names and 'a’s. 


305e. (support for names and environments 303) += (S213a) <1305d 305f> 


bindList : name list * 'a list * 'a env -> 'a env 


exception BindListLength mkEnv : name list * 'a list -> 'a env 


fun bindList (x::vars, v::vals, rho) = bindList (vars, vals, bind (x, v, rho)) 
| bindList ([], [], rho) = rho 
| bindList _ = raise BindListLength 


type name 303 
fun mkEnv (xs, vs) = bindList (xs, vs, emptyEnv) 
Finally, environments can be composed using the + operator. In my ML code, 
this operator is implemented by function <+>, which I declare to be infix. It uses 
the predefined infix function @, which is ML’s way of writing append. 
305f. (support for names and environments 303) += (S213a) <305e 


(* composition *) <+> : 'a env * 'a env -> 'a env 
infix 6 <+> 


fun pairs <+> pairs' = pairs' @ pairs 


Function <+> obeys the algebraic law bindList(zs, vs, 9) = p<+>mkEnv(2s, US). 
Later chapters use <+> and mkEnv instead of bindList. 
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Table 5.2: Exceptions defined for my interpreters 


Exceptions raised at run time 


NotFound A name was looked up in an environment but not found there. 


BindListLength Acallto bindList tried to extend an environment, but it passed 
two lists (names and values) of different lengths (also raised by 
mkEnv). 


RuntimeError Something else went wrong during evaluation, i.e., during the 
execution of eval. 


5.2 ABSTRACT SYNTAX AND VALUES 


An abstract-syntax tree can contain a literal value. A value, if it is a closure, can 
contain an abstract-syntax tree. These two types are therefore mutually recursive, 
so they must be defined together, using and. 

These particular types use as complicated a nest of definitions as you'll ever see. 
The keyword datatype defines a new algebraic datatype; the keyword withtype 
introduces a new type abbreviation that is mutually recursive with the datatype. 
The first two and keywords define additional algebraic datatypes, and the third and 
keyword defines an additional type abbreviation. Everything in the whole nest is 
mutually recursive. 


306. (definitions of exp and value for Scheme 306) = (S380a) 
datatype exp = LITERAL of value 
VAR of name 
SET of name * exp 
IFX of exp * exp * exp 


WHILEX of exp * exp 

BEGIN of exp list 

APPLY of exp * exp list 

LETX of let_flavor * (name * exp) list * exp 
LAMBDA of lambda 

and let_flavor = LET | LETREC | LETSTAR 


and value = SYM of name 
NUM of int 
BOOLV of bool 
NIL 
PAIR of value * value 


CLOSURE of lambda * value ref env 
PRIMITIVE of primitive 
withtype primitive = exp * value list -> value (* raises RuntimeError *) 


and lambda = name list * exp 


The representations are the same as in C, with these exceptions: 


* In a LETX expression, the bindings are represented by a list of pairs, not a 
pair of lists—just like environments. 


* In the representation of a primitive function, there’s no need for an inte- 
ger tag. As shown in Section 5.4 below, ML's higher-order functions makes 
it easy to create groups of primitives that share code. Tags would be useful 
only if we wanted to distinguish one primitive from another when printing. 


* None of the fields of exp, value, or lambda is named. Instead of being re- 
ferred to by name, these fields are referred to by pattern matching. 


A primitive function that goes wrong raises the RuntimeError exception, which is 
the ML equivalent of calling runerror. 
True definitions are as in the C code, except again, fields are not named. 
307. (definition of def for Scheme 307a)= (S380a) 
datatype def = VAL of name * exp 
| EXP of exp 
| DEFINE of name * lambda 


Unit tests and other extended definitions are relegated to Appendix O. 
The rest of this section defines utility functions on values. 


String conversion 


Instead of printf, ML provides functions that can create, manipulate, and com- 
bine strings. So instead using something like Chapter 1’s extensible print func- 
tion, this chapter builds strings using string-conversion functions. One example, 
valueString, which converts an ML value to a string, is shown here. The other 
string-conversion functions are relegated to the Supplement. 

Function valueString is primarily concerned with S-expressions. An atom is 
easily converted, but a list made up of cons cells (PAIRs) requires care; the cdr is 
converted by a recursive function, tail, which implements the same list-printing 
algorithm as the C code. (The algorithm, which goes back to McCarthy, is imple- 
mented by C function printtail on page S332.) Function tail is defined inside 
valueString, with which it is mutually recursive. 


307b. (definition of valueString for Scheme, Typed Scheme, and nano-ML 307b)= _—(S380a 
fun valueString (SYM v) ay valueString : value -> string 
| valueString (NUM n) = intString n 
| valueString (BOOLV b) = if b then "#t" else "#f" 
| valueString (NIL) =" 
| valueString (PAIR (car, cdr)) = 
let fun tail (PAIR (car, cdr)) = " " A valueString car A tail cdr 
| tail NIL = ")" 
| tail v=" ." A valueString v A ")" 
in "c" A valueString car A tail cdr 
end 
| valueString (CLOSURE _) = "<function>" 
| valueString (PRIMITIVE _) = "<function>" 


Function valueString demonstrates pattern matching. It takes one argument and 
does a case analysis on its form. Each case corresponds to a clause in the defini- 
tion of valueString; there is one clause for each datatype constructor of the value 
type. On the left of the =, each clause contains a pattern that applies a datatype con- 
structor to a variable, to a pair of variables, or to the special “wildcard” pattern _ 
(the underscore). Each variable, but not the wildcard, is introduced into the envi- 
ronment and is available for use on the right-hand side of the clause, just as if it 
had been bound by a pzScheme let or ML val. 

From the point of view of a C programmer, a pattern match combines a switch 
statement with assignment to local variables. The notation is sweet; for example, 
in the matches for BOOLV and PAIR, I like b and car much better than the v.u.boolv 
and v.u.pair.car that I have to write in C. And I really like that the variables b and 
car can be used only where they are meaningful—in C, v.u.pair.car is accepted 
whenever v has type Value, but if v isn’t a pair, the reference to its car is mean- 
ingless (and to evaluate it is an unchecked run-time error). In ML, only meaningful 
references are accepted. 
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Embedding and projection 


Inside the interpreter, Scheme values sometimes need to be converted to or from 
ML values of other types. 


+ When it sees a quote mark and brackets, the parser defined in the Supple- 
ment produces a native ML list of S-expressions represented by a combina- 
tion of [] and ::. But the evaluator needs a Scheme list represented by a 
Interlude: combination of NIL and PAIR. 


PSHE EMAL * When it evaluates a condition in a puScheme if expression, the evaluator pro- 


308 duces a psScheme value. But to test that value with a native ML if expression, 
the evaluator needs a native ML Boolean. 


Such needs are met by using functions that convert values from one language to an- 
other. Similar needs arise whenever one language is used to implement or describe 
another, and to keep two such languages straight, we typically resort to jargon: 


* The language being implemented or described—in our case, wScheme—is 
called the object language. 


* The language doing the describing or implementation—in our case, ML—is 
called the metalanguage. (The name ML actually stands for “metalanguage.”) 


To convert, say, an integer between object language and metalanguage, we use 
a pair of functions called embedding and projection. The embedding puts a metalan- 
guage integer into the object language, converting an int into a value. The projec- 
tion extracts a metalanguage integer from the object language, converting a value 
into an int. If the value can’t be interpreted as an integer, the projection fails.’ 
The embedding/projection pair for integers is defined as follows: 


308a. (utility functions on values (tuScheme, Typed juScheme, nano-ML) 308a) = (S379) 308bb> 
fun embedInt n = NUM n embedInt : int -> value 
fun projectInt (NUM n) =n projectInt : value -> int 


| projectInt v = 
raise RuntimeError ("value " A valueString v 4 " is not an integer") 
Embedding and projection for Booleans is a little different; unlike some pro- 
jection functions, projectBool is total: it always succeeds. Function projectBool 
reflects the operational semantics of wScheme, which treats any value other than 
#f as a true value.” 


308b. (utility functions on values (uScheme, Typed Scheme, nano-ML) 308a) += ($379) <308a 308c > 


fun embedBool b = BOOLV b embedBool : bool -> value 
fun projectBool (BOOLV false) = false projectBool : value -> bool 
| projectBool _ = true 


The same Boolean projection function is used in Chapter 2, but without the jargon; 
there, the projection function is called istrue. 

A list of values can be embedded as a single value by converting ML’s :: and [] 
to zScheme’s PAIR and NIL. The corresponding projection is left as Exercise 4. 
308c. (utility functions on values (Scheme, Typed Scheme, nano-ML) 308a) += (S379) <1 308b 


fun embedList [] = NIL embedList : value list -> value 
| embedList (h::t) = PAIR (h, embedList t) 


In general, we embed a smaller set into a larger set. Embeddings don’t fail, but projections might. 
A mathematician would say that an embedding e¢ of S into S’ is an injection from S — S$’. The corre- 
sponding projection 7¢ is a left inverse of the embedding; that is 7¢ © e is the identity function on S. 
There is no corresponding guarantee for e o 7; for example, 7- may be undefined () on some ele- 
ments of S’, or e(7¢(x)) may not equal «. 

A Boolean projection function formalizes the concepts of “truthy” and “falsy” found in languages 
like JavaScript: a value is truthy if it projects to true and falsy if it projects to false. 


5.3. EVALUATION 


The machinery above is enough to write an evaluator, which takes an expres- 
sion and an environment and produces a value. Because the environment rarely 
changes, my evaluator is structured as a nested pair of mutually recursive func- 
tions. The outer function, eval, takes both expression e and environment rho as 
arguments. The inner function, ev, takes only an expression as argument; it uses 
the rho from the outer function. 


Function ev begins with a clause that evaluates a LITERAL form, which evaluates a ; 
: Evaluation 
to the carried value v. 
309a. (definitions of eval and evaldef for Scheme 309a)= 311b> 309 
fun eval (e, rho) = eval : exp * value ref env -> value 
let fun ev (LITERAL v) = v ev 3 exp ~> value 
(more alternatives for ev for Scheme 309b) 
in eve 
end 
A VAR or SET form looks up a name x in rho. The name is expected to be bound 
toa mutable reference cell, which is ML’s version ofa pointer to a location allocated 
on the heap. Such locations are read and written not by using special syntax like 
C’s *, but by using functions ! and :=, which are in the initial basis of Standard ML. 
(The := symbol, like the + symbol, is an ordinary ML function that is declared to be 
infix.) 
309b. (more alternatives for ev for uScheme 309b) = (309a) 309c > 
| ev (VAR x) = !(find (x, rho)) 
| ev (SET (x, e)) = 
let val v = eve 
in find (x, rho) := v; 
Vv 
end 
Because the right-hand side of SET, here called e, is evaluated in the same environ- BEGIN 306 
ment as the SET, it can be evaluated using ev. =tatoHL 306 
An IF or WHILE form must interpret a jsScheme value as a Boolean. Both forms a ee Bs: 
use the projection function projectBool. eaynil 305b 
309¢. (more alternatives for ev for Scheme 309b) += (309a) <309b 309d> BPA 306 
| ev (IFX (e1, e2, e3)) = ev (if projectBool (ev e1) then e2 else e3) cae oe 
| ev (WHILEX (guard, body)) = NUM 306 
if projectBool (ev guard) then PAIR 306 
(ev body; ev (WHILEX (guard, body))) RuntimeError 
else $213b 
BOOLV false SIE 306 
type value 306 
The code used to evaluate a while loop is nearly identical to the rule for lowering valueString 307b 
while loops in Chapter 3 (page 214). VAR 306 
WHILEX 306 


A BEGIN form is evaluated by evaluating its subexpressions in order, retaining 
the value of the last one. The subexpressions are evaluated by auxiliary function b, 
which remembers the value of the last expression in an accumulating parameter 
lastval. To ensure that an empty BEGIN is evaluated correctly, lastval is initially 
a Scheme #f. 
309d. (more alternatives for ev for uScheme 309b) += (309a) <309c 310a> 

| ev (BEGIN es) = 
let fun b (e::es, lastval) = b (es, ev e) 
| b ¢ [], lastval) = lastval 
in b (es, BOOLV false) 
end 
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A LAMBDA form captures a closure, which is as simple as in C. 


310a. (more alternatives for ev for jScheme 309b) += (309a) «309d 310b> 
| ev (LAMBDA (xs, e)) = CLOSURE ((xs, e), rho) 


An application is evaluated by first evaluating the expression f that appears in 
the function position. How the result is applied depends on whether f evaluates to 
a primitive or a closure. As in C, a primitive is applied by applying it to the syntax e 
and to the values of the arguments. 
310b. (more alternatives for ev for puScheme 309b) += (309a) 1310a 310d> 

| ev (e as APPLY (f, args)) = 
(case ev f 
of PRIMITIVE prim => prim (e, map ev args) 
| CLOSURE clo => (apply closure clo to args 310c) 
| v => raise RuntimeError 
("Applied non-function " A valueString v) 


) 


The pattern e as APPLY (f, args) matches an APPLY node. On the right-hand side, 
e stands for the entire node, and f and args stand for the children. 

A closure is applied by first creating fresh locations to hold the values of the 
actual parameters. In Chapter 2, the locations are allocated by function allocate; 
here, they are allocated by the built-in function ref. Calling ref v allocates a new 
location and initializes it to v. The ML expression map ref actuals does half the 
work of Chapter 2’s bindalloclist; the other half is done by bindList. 
310c. (apply closure clo to args 310c)= (310b) 

let val ((formals, body), savedrho) = clo 
val actuals = map ev args 
in eval (body, bindList (formals, map ref actuals, savedrho)) 
handle BindListLength => 
raise RuntimeError ("Wrong number of arguments to closure; " A 
"expected (" A spaceSep formals A ")") 
end 


If the number of actual parameters doesn’t match the number of formal param- 
eters, bindList raises the BindListLength exception, which eval catches using 
handle. The handler then raises RuntimeError. 

A LET form is most easily evaluated by first unzipping the list of pairs bs into a 
pair of lists (names, rightSides); function ListPair.unzip is from the ListPair 
module in ML’s Standard Basis Library. Each right-hand side is then evaluated 
with ev and stored in a fresh location by ref. To do the whole list at once, I use 
map with the function composition rev o ev. Finally, the body of the LET is evalu- 
ated in a new environment built by bindList; since ev works only with the current 
rho, the body must be evaluated by eval. 


310d. (more alternatives for ev for uScheme 309b) += (309a) <310b 310e> 
ListPair.unzip : ('a * 'b) list -> 'a list * 'b list 
| ev (LETX (LET, bs, body)) = 

let val (names, rightSides) = ListPair.unzip bs 

in eval (body, bindList (names, map (ref 0 ev) rightSides, rho)) 

end 


A LETSTAR form, by contrast, is more easily evaluated by walking the bindings one 
pair at atime. 
310e. (more alternatives for ev for Scheme 309b) += (309a) <1310d 31la> 
| ev (LETX (LETSTAR, bs, body)) = 
let fun step ((x, e), rho) = bind (x, ref (eval (e, rho)), rho) 
in eval (body, foldl step rho bs) 
end 


As in Chapter 2, a LETREC form is evaluated by first building a new environment 
rho' that binds each name to a fresh location, then evaluating each right-hand side 
in the new environment, updating the fresh locations, and finally evaluating the 
body. The updates are performed by List.app, which, just like jzScheme’s app, ap- 
plies a function to every element of a list, just for its side effect. Functions List .app 
and map are used here with anonymous functions, each of which is written with fn— 
which is ML’s way of writing lambda. 


311a. (more alternatives for ev for j1Scheme 309b) += (309a) <1310e §5.3 


List.app : ('a -> unit) -> 'a list -> unit Evaluation 


| ev (LETX (LETREC, bs, body)) = 


let val (names, rightSides) = ListPair.unzip bs 311 
val rho' = 
bindList (names, map (fn _ => ref (unspecified())) rightSides, rho) 
val updates = map (fn (x, rightSide) => (x, eval (rightSide, rho'))) bs 
in List.app (fn (x, v) => find (x, rho') := v) updates; 
eval (body, rho') 
end 
5.3.1 Evaluating definitions 
As in Chapter 2, true definitions are evaluated by evaldef. This function takes a 
definition and an environment, and it returns a new environment and the inter- 
preter’s (string) response. (The C versions of evaldef in Chapters 1 and 2 print the 
response, but the ML code in this chapter is used not only for uScheme, but also for 
statically typed languages in Chapters 6 to 8. For those languages, it is better to re- 
turn a response from evaluation, so the response from evaluation can be combined 
with a response from type checking.) 

When a definition introduces a new name, that definition is evaluated in an FEY ae 
environment that already includes the name being defined. If the name x is not al- rata 305d 
ready bound, the NotFound exception is handled, and x is bound to a fresh location bindList  305e 
that is initialized with an unspecified value. euinGl Luisi lLenneeseh 
311b. (definitions of eval and evaldef for Scheme 309a) += <1309a 311c> CLOSURE es 

withNameBound : name * value ref env -> value ref env type def 307a 

type env 304 

fun withNameBound (x, rho) = au 309a 
(find (x, rho); rho) eval 309a 
handle NotFound _ => bind (x, ref (unspecified ()), rho) find 305b 

: rere’ ; , LAMBDA 306 

Given a VAL form with binding to name x and right-hand side e, evaldef first Lea 306 
uses withNameBound to make sure x is bound to a location in the environment. LETREC 306 
It then evaluates e and stores its value in x’s location. It also computes a response, LETSTAR 306 
which is usually the value. But if the definition binds a lambda expression, the re- noe 206 
sponse is instead the name x. neat Be 
311c. (definitions of eval and evaldef for wScheme 309a) += <1311b 312ap PRIMITIVE 306 

evaldef : def * value ref env -> value ref env * string bate ; ava 
RuntimeError 
fun evaldef (VAL (x, e), rho) = $213b 
let val rho = withNameBound (x, rho) spaceSep S$214e 
val v = eval (e, rho) unspecified S389c 
val _ = find (x, rho) :=v as enti ae 
val response = case e of LAMBDA _ => x valueString 307b 


| _ => valueString v 
in (rho, response) 
end 
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As in Chapter 2, define is syntactic sugar for val with lambda. 
312a. (definitions of eval and evaldef for uScheme 309a) += <31lc 312b> 
| evaldef (DEFINE (f, lambda), rho) = 
let val (xs, e) = lambda 
in evaldef (VAL (f, LAMBDA lambda), rho) 
end 


The EXP form doesn't bind a name; evaldef just evaluates the expression, binds 
the result to it, and responds with the value. 
312b. (definitions of eval and evaldef for Scheme 309a) += <312a 
| evaldef (EXP e, rho) = 
let val v = eval (e, rho) 
val rho = withNameBound ("it", rho) 
val _ = find ("it", rho) := v 
in (rho, valueString v) 
end 
The differences between VAL and EXP are subtle: for VAL, the semantics demands 
that the name be added to environment rho before evaluating expression e. For EXP, 
the name it isn’t bound until after evaluating the first EXP form. 


5.4 DEFINING AND EMBEDDING PRIMITIVES 


pScheme primitives like + and cons have ML counterparts like + and PAIR. But the 
ML counterparts operate on ML values, and the ;sScheme versions must operate 
on sScheme values. Each jsScheme primitive is implemented just as in Chapter 2 
(chunk 161b): take ;sScheme values as arguments, project them to ML values, apply 
an ML primitive, and embed the ML result into Scheme. But the code is structured 
differently: instead of projecting arguments and embedding a result, I embed the 
function. Each primitive function is written with its own most natural ML type, 
then is embedded into the type of Scheme primitives: exp * value list -> value. 
The embedding takes care of the function's arguments and results. (Because no 
LScheme function ever acts as an ML function, a corresponding projection is not 
needed.) 

The embedding for a function depends on the function’s type. Each embedding 
is composed of other functions, which gradually “lift” a primitive function from 
its native ML type to type exp * value list -> value. For example, the primitive 
function + passes through these types: 


ML primitive + has type int * int -> int. 


The primitive is embedded into a function that operates on jsScheme values; 
its type is now lifted to value * value -> value. 


The lifted function is embedded into a function that can be applied to a list 
of values; after this second lifing, its type is now value list -> value. 


Finally, the twice-lifted function is embedded into a function that is given not 
just a list of values but also the syntax of the expression in which the puScheme 
primitive appears; its final type is exp * value list -> value, which is the 
type of the primitive used in the evaluator. 


Let’s look at these lifting steps in reverse order, from last to first. 


The final lifting step is given a function f of type value list -> value, and 
it produces a new function inExp f of type exp * value list -> value. The new 
function applies f, and if applying f raises the RuntimeError exception, it handles 
the exception, adds to the error message, and re-raises the exception. 
313a. (utility functions for building primitives in Scheme 313a)= (S382a) 313b> 
inExp : (value list -> value) -> (exp * value list -> value) 


fun inExp f = 
fn (e, vs) => f vs 
handle RuntimeError msg => 
raise RuntimeError ("in " A expString e 4", " A msg) 


The middle lifting step is given a function f that takes one or two arguments 
of type value and returns a result of type value, and it produces a new func- 
tion unaryOp f or binaryOp f of type value list -> value. The new function uses 
pattern matching to extract the expected number of arguments and pass them 
to f. If the number of arguments is unexpected, function arityError raises 
RuntimeError. 


313b. (utility functions for building primitives in Scheme 313a) += ($382a) 1313a 313c> 


unaryOp : (value -> value) -> (value list -> value) 
binaryOp : (value * value -> value) -> (value list -> value) 


fun arityError n args = 
raise RuntimeError ("expected " A intString n A 
"but got " A intString (length args) 4 " arguments") 
fun unaryOp f (fn [a] => fa | args => arityError 1 args) 
fun binaryOp f = (fn [a, b] => f (a, b) | args => arityError 2 args) 


Functions unaryOp and binaryOp help implement any Scheme primitive that is a 
“unary operator” or “binary operator.” 

The first lifting step is given a function like + that expects and returns ML 
integers, and it produces a new function arithOp + of type value list -> value. 
The anonymous function passed to binaryOp has type value * value -> value. 


313¢. (utility functions for building primitives in Scheme 313a) += (S382a) 1313b 314a> 
arithOp: (int * int -> int) -> (value list -> value) 
fun arithOp f = binaryOp (fn (NUM ni, NUM n2) => NUM Cf (ni, n2)) 

| (NUM n, v) => (report v is not an integer 314b) 

| (v, _) => (report v is not an integer 314b) 


) 


Now piScheme primitives like + and * can be defined by applying first arithOp and 
then inExp to their ML counterparts. 

The pScheme primitives are organized into a list of (name, function) pairs, in 
Noweb code chunk (primitives for zScheme :: 313d). Each primitive on the list has 
type value list -> value. In chunk $382a, each primitive is passed to inExp, and 
the results are used build u~Scheme’s initial environment.’ The list of primitives 
begins with these four elements: 


313d. (primitives for Scheme :: 313d)= (S382a) 314c> 
c"+", arithOp op + ) 
c"-", arithOp op - ) 
c'™*",) arithOp op * ) 
c"/", arithOp op div) 


The ML keyword op converts an infix identifier to an ordinary value, so arithOp op + 
passes the value + (a binary function) to the function arithOp. 


3 Actually, the list contains all the primitives except one: the error primitive, which must not be 
wrapped in inExp. 
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DEFINE 307a 
eval 309a 
evaldef 311c 
EXP 307a 
type exp 306 
expString S383b 


find 305b 
intString $214c 
LAMBDA 306 
NUM 306 
RuntimeError 
$213b 
VAL 307a 


type value 306 
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Primitives like < and nu11? return Booleans, so they can’t be lifted by arithOp. 
For primitives like these, the first and middle lifting steps are performed by func- 
tions predOp, comparison, and intcompare. 


314a. (utility functions for building primitives in Scheme 313a) += (S382a) <1313c 
predOp : (value -> bool) -> (value list -> value) 
comparison : (value * value -> bool) -> (value list -> value) 
intcompare : (int * int -> bool) -> (value list -> value) 
fun predOp f = unaryOp (embedBool o f) 


fun comparison f = binaryOp (embedBool o f) 

fun intcompare f = comparison (fn (NUM ni, NUM n2) => f (ni, n2) 
| (NUM n, v) => (report v is not an integer 314b) 
| (v, _) => (report v is not an integer 314b) 


314b. (report v is not an integer 314b)= (313c 314a) 
raise RuntimeError ("expected an integer, but got " A valueString v) 


LScheme’s primitive predicates are implemented by ML primitives (< and >), 
by function equalatoms (defined in Appendix O), and by anonymous functions. 
314c. (primitives for uScheme :: 313d) += (S382a) <313d 

c("<", intcompare op <) :: 

(">", intcompare op >) :: 

("=", comparison equalatoms) :: 

C"null?", predOp (fn (NIL ) => true | _ => false)) :: 

("boolean?", predOp (fn (BOOLV _) => true | _ => false)) :: 
The remaining type predicates, the list primitives, and the printing primitives are 
defined in Appendix O. 


5.5 NOTABLE DIFFERENCES BETWEEN ML AND C 


The ML interpreter presented in Sections 5.3 and 5.4 uses the same overall design 
as the C interpreters of Chapters 1 and 2. But the many small differences in the two 
languages add up to a different programming experience; the ML version is more 
compact and more reliable. The two experiences compare as follows: 


* Both interpreters allocate mutable locations on the heap, which they operate 
on with C pointer syntax (*) or ML primitive functions (! and :=). The C code 
leaks memory like crazy; plugging all the leaks would require a garbage col- 
lector considerably more elaborate than the one in Chapter 4. ML ships with 
a comprehensive garbage collector built in. 


Both interpreters use the same abstraction to represent abstract syntax trees: 
a tagged sum of products. Thanks to the little data-description language of 
Chapter 1, the representations are even specified similarly. But C’s unions 
are unsafe: making the alt tag consistent with the payload is up to the pro- 
grammer. ML's algebraic data types guarantee consistency. The C code does 
offer one advantage, however: in the source code, the definitions of struct 
Value and struct Exp can appear separately. In the ML code, the definitions 
value and exp, because they are mutually recursive, must appear adjacent in 
the source code so they can be connected with and. 


* Both interpreters manage run-time errors in the same way. An error may be 
detected and signaled anywhere; C code uses runerror, which calls longjmp 
(in C), and ML code uses raise. And in both interpreters, an error once de- 
tected is handled in a central place, using set jmp or handle, as described in 
the Supplement. 


* Both interpreters use functions, like “length of a list” and “find a name in an 
environment,” that could in principle be polymorphic. But only ML code can 
define a function that is actually polymorphic. The C code in Chapters 1 and 2 
must define a new length function for every type of list and a new find func- 
tion for every type of environment. 


C code can use printf, and it can even define new functions that resemble 
printf, like print. ML code has nothing comparable: because the ML type 
checker won't check the types of the arguments based on a format string, 
ML code can only print strings—so it must use string-conversion functions. 


To define primitives, both interpreters use first-order embedding and pro- 
jection functions to embed and project numbers (projectint32 and mkNum 
or projectInt and embedInt) and Booleans. But only the ML code can em- 
bed functions, using binaryOp, intcompare, and so on. And in ML, opera- 
tions like / and div are functions, not syntax, so they can be embedded into 
pScheme directly. Their counterparts in C require significant “glue code.” 


5.6 FREE AND BOUND VARIABLES: DEEPER INTO WSCHEME 


The ML implementation of piScheme is easier to modify than the C version. And 
no matter what mistakes you make, the ML code cannot dump core or fail with 
inexplicable pointer errors. These properties make ML a good vehicle for explor- 
ing techniques that are actually used to implement functional languages (Exer- 
cises 9 and 10, pages 324 and 325). These techniques rely on a crucial concept in 
programming languages: the distinction between free and bound variables. 

When an expression e refers to a name y that is introduced outside of e, we 
say that y is free in e. Such names are called “free variables,” even though “free 
names” would be more accurate. A variable in e that is introduced within e is a 
bound variable. For example, in the expression 


(lambda (n) (+ 1 n)) 


the name + is a free variable, but nis a bound variable. Every variable that appears 
in an expression is either free or bound. 
Each variable that appears in a definition is also free or bound. For example, in 


(define map (f xs) 
(if (null? xs) 
m0) 
(cons (f (car xs)) (map f (cdr xs))))) 


the names null1?, cons, car, and cdr are free, and the names map, f, and xs are 
bound. (And if is not a name; it is a reserved word that, like if in ML or C, marks a 
syntactic form.) 

Free variables enable compilers to represent closures efficiently. According to 
the operational semantics, evaluating a lambda expression captures the entire en- 
vironment p<: 


@1,..-,Xy all distinct 


(LAMBDA((21,..-,2n),€), Pc, 0) 4) ((LAMBDA((21,...,2n),€), Pc ),o). 
(MKCLOSURE) 
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NIL 306 
NUM 306 
RuntimeError 
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Does the closure really need all the information in p,? How is p, used? 


£1,...,ln ¢ dom oy (and all distinct) 


(e, p,o) |) ((LAMBDA((21,.--,2%n),€c); Pe), Oo) 
(e1,P, 20) ¥ (v1, 01) 


Cai PeOnay Ava Be} 
(€e; Pce{X1 + L1,..-,8n Enh, on{Ai > U1,-.-,n 2 Unt) I (vu, 0") 


(APPLY(e, El,+-- ,€n); Pp; a) Y (v, a’) 


(APPLYCLOSURE) 

Environment p- is used only to evaluate the body of the LAMBDA. So the MKCLO- 

SURE rule need not store all of o.—it needs only those bindings that refer to vari- 

ables that are free in the LAMBDA expression (Exercise 9). You can use this fact to 
make the interpreter faster (Exercise 10). 

To do Exercises 9 and 10, you need a precise definition of what a free variable is. 

And precision calls for formal judgments and proofs. The judgment form for iden- 


tifying free variables in an expression is| y € fv(e) | The notation fv(e) refers to 


the set of all variables that appear free in e, but constructing the set is not neces- 
sary, and the judgment y € fv(e) should be pronounced as “y appears free in e.” 
The judgment may be provable in different ways for each syntactic form. 
A literal expression has no free variables. Formally speaking, no judgment of 
the form y € fv(LITERAL(v)) can ever be proved, so there is no rule for literals. 
Alone variable x is always free. 


x € fv(vAR(a)) 


A variable is free in a SET expression if it is assigned to or if it is free in the right- 
hand side. So a SET expression has two proof rules: 
y € fv(e) 
x € fv(sET(z, e)) y € fv(SET(z, e)) 


A variable is free in an IF expression if and only if it is free in one of the subexpres- 
sions: 


y € fv(ez) y € fv(e2) y € fv(e3) 
y € fv(1F(e1, €2, €3)) y € fv(1F(e1, €2, €3)) y € fv(IF(e1, €2, €3)) 


A variable is also free in a WHILE expression if and only if it is free in one of the 
subexpressions: 


y € fv(e1) y € fv(e2) 
y € fv(WHILE(e;, €2)) y € fv(WHILE(€), €2)) 


And the same for BEGIN: 


y € fv(e;) 
y € fv(BEGIN(€1,...,€n)) 


A variable is free in an application if and only if it is free in the function or in one 
of the arguments: 


y € fv(e) y € fv(e;) 
y € fv(APPLY(e, €1,...,€n)) y € fv(APPLY(e, €1,..-,€n)) 


Finally, an interesting case! A variable is free in a LAMBDA expression if it is free in 
the body and it is not one of the arguments: 


y € fv(e) y € {x1,..., Ln} 
y € fv(LAMBDA((a1,...,2n), €)) 


The various LET forms require care. A variable is free in an ordinary LET if it is 
free in the right-hand side of any binding, or if it is both free in the body and not 
bound by the LET. 


y € fv(er) Ome Cee 
y € fv(LET((@1,€1,---,%n,€n), €)) y € fv(LET((@1,€1,.--,;%n,€n),€)) 


The similarity between the second LET rule and the LAMBDA rule shows a kinship 
between LET and LAMBDA. 

The rules for LETREC are almost identical to the rules for LET, except that ina 
LETREC, the bound names 1; are never free: 


y € fv(e;) YE Bry ey Wy | 
y € fv(LETREC((21, €1,---,%n,€n), €)) 


y € fv(e) y € {x1,...,0n} 
y € fv(LETREC((21, €1,---,%n,€n), €)) 


As usual, a LETSTAR rule would be a nuisance to write directly. Instead, I treat 
a LETSTAR expression as a set of nested LET expressions, each containing just one 
binding. And an empty LETSTAR behaves just like its body. 


y € fv(LET((a1, €1), LETSTAR((@2, €2,.--,%n,€n), €))) 
y € fv(LETSTAR((a1,€1,---,@n;€n), €)) 
y € fv(e) 


y € fv(LETSTAR((), e)) 


5.7 SUMMARY 


By exploiting algebraic data types, pattern matching, higher-order functions, and 
exceptions, we can make interpreters that are simpler, smaller, easier to read, more 
reliable, and more flexible than interpreters we can write in C. 


5.7.1 Key words and phrases 


ALGEBRAIC DATATYPE A representation defined by a set of VALUE CONSTRUC- 
TORS. Every value of the type is made by using or applying one of the 
type’s value constructors. An algebraic data type is defined with the keyword 
datatype. Mutually recursive algebraic data types are defined with an initial 
datatype, and individual definitions are separated by keyword and. 


BOUND VARIABLE A variable introduced by a function definition or other construct 
and whose meaning is independent of any appearance of its name outside 
the construct. Formal parameters of functions are bound variables, as are 
variables introduced by let forms. Variables that aren’t bound are FREE. 
The name of a bound variable can be changed without changing the meaning 
of the program, provided the new name does not conflict with any variable 
that is free in the scope of the binding. 
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CLAUSAL DEFINITION A syntactic form of definition that combines a function def- 
inition and a PATTERN MATCH. It is introduced with the keyword fun, and 
arms of the pattern are separated by vertical bars. Unlike an ordinary pat- 
tern match that is used with case or hand1e, the pattern match in a clausal 
definition begins with the name of the function being defined. 


A clausal definition is the idiomatic way to define an ML function that be- 
gins with a pattern match. It is preferred over a function whose body is a 
case expression. 


EMBEDDING A mapping from METALANGUAGE values to OBJECT-LANGUAGE val- 
ues. The mapping always succeeds. For example, any ML int can be mapped 
to a Scheme value. An embedded value can be mapped back to the meta- 
language by a PROJECTION. 


EXCEPTION A way of signaling a named error condition. Exceptions replace C’s 
longjmp. An exception acts like a VALUE CONSTRUCTOR: it can stand by itself, 
or it can carry one or more values. In ML, evaluating an expression may raise 
an exception, produce a value, or cause a checked run-time error. 


EXCEPTION HANDLER Code that is executed when an exception is raised. Excep- 
tion handlers replace C’s setjmp. An exception handler may include a PAT- 
TERN MATCH that determines which exceptions are handled. Our inter- 
preter’s primary exception handlers are associated with the GENERIC READ- 
EVAL-PRINT LOOP. 


EXHAUSTIVE PATTERN MATCH A pattern match that is guaranteed to match every 
possible value. Pattern matches should be exhaustive. If you write one that is 
not exhaustive, the ML compiler is required to warn you. You should deploy 
compiler options which turn that warning into an error. 


FREE VARIABLE A variable that is defined outside the function in which it appears. 
The meaning of a free variable depends on context. The idea of free variable 
generalizes beyond function definitions to include any language construct 
that introduces new variables, like a let expression. Variables that aren't 
free are BOUND. 


INTERACTIVITY A term I coined to describe the behavior of the READ-EVAL-PRINT 
LOOP. Interactivity determines whether the loop prompts the user before 
reading input, and whether it prints after evaluating a definition. 


LIST CONSTRUCTOR Special syntax for writing lists and list patterns in ML. Instead 
of using cons (written ::) and nil, a list constructor uses square brackets 
containing zero or more elements separated by commas. If the list construc- 
tor appears as an expression, each element is an expression. If the list con- 
structor appears as a PATTERN, each element is a pattern. 


METALANGUAGE In an interpreter, the language in which the interpreter is imple- 
mented. Ina semantics, the language used for semantic description. A meta- 
language describes an OBJECT LANGUAGE. In this chapter, the metalanguage 
is Standard ML. (The ML in Standard ML stands for “metalanguage.”) 


MUTABLE REFERENCE CELL A location allocated on the heap. In ML, variables 
stand for values, not for locations, so the only way to get a location is to 
allocate a mutable reference cell. A reference cell containing a value of 
type T has type 7 ref. It is created by primitive function ref, which acts 
like uScheme’s allocate function (page 154). It is dereferenced by primitive 


function !, which acts like C’s dereferencing operator *. It is mutated by the 
infix primitive function :=; the ML expression p := e is equivalent to the C 
expression *p = e. 


MUTUAL RECURSION (CODE) Two or more functions, each of which can call the 
other. In ML, many mutually recursive functions are defined by nesting the 
definition of one inside the definition of the other. When both have to be 
called from outside, they can be defined at the same level using keywords 
fun and and. Mutually recursive functions can also be defined in C style, us- 
ing mutable reference cells. 


MUTUAL RECURSION (DATA) Two or more ALGEBRAIC DATA TYPES, each of which 
can contain a value of another. Defined using datatype and keyword and; 
in ML, the and always signifies mutual recursion. In most languages in this 
book, types exp and value are mutually recursive: an exp can contain a literal 
value, and a value might be a closure, which contains an exp. 


OBJECT LANGUAGE In an interpreter, the language being implemented. In a se- 
mantics, the language being described. An object language is described by a 
METALANGUAGE. In this chapter, the object language is wScheme. 


PATTERN A variable, which matches anything, or a VALUE CONSTRUCTOR applied 
to zero or more patterns, which matches only a value created with that con- 
structor. Or a tuple of patterns. 


PATTERN MATCHING The computational process by which a value of ALGEBRAIC 
DATA TYPE is observed. A pattern match comprises an expression being ob- 
served, called the SCRUTINEE, and a list of arms, each of which has a PATTERN 
on the left and an expression on the right. The first pattern that matches 
the scrutinee is chosen, and the corresponding right-hand side is evaluated. 
Pattern matching may be used in a case expression, in an EXCEPTION HAN- 
DLER, or in a CLAUSAL DEFINITION. Pattern matching is explained at length 
in Chapter 8. 


POLYMORPHIC TYPE A type with one or more TYPE VARIABLES. A value or func- 
tion with a polymorphic type may be used with any type replacing the type 
variable. For example in type 'a env, the 'a may stand for value ref, which 
gives us environments that store MUTABLE REFERENCE CELLS. 


PROJECTION A mapping from OBJECT-LANGUAGE values to METALANGUAGE val- 
ues. The mapping might fail. For example, the wScheme value 3 cannot 
meaningfully be projected into an ML function. A projection is the inverse 
of an EMBEDDING; an attempt to project an embedded value should recover 
the original value. And some projections, like bool in chunk 308b, always 
succeed—in a Boolean context, every juScheme value is meaningful. 


READ-EVAL-PRINT LOOP The control center of an interactive interpreter. It reads 
concrete syntax and parses it into abstract syntax, it evaluates the abstract 
syntax, and it prints the result. If an EXCEPTION is raised during evaluation, 
the exception is handled in the read-eval-print loop, and looping continues. 
The read-eval-print loop in Appendix O is reused throughout this book; in 
every language, it handles extended definitions. True definitions are handled 
by function processDef, which is different in each interpreter. 


REDUNDANT PATTERN An arm in a PATTERN MATCH that is guaranteed never to be 
evaluated, because any values it might match are matched by preceding pat- 
terns. A redundant pattern match is a sign of a bug in your code—perhaps a 
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misspelling of a VALUE CONSTRUCTOR. Most ML compilers warn you of re- 
dundant patterns. You should deploy compiler options which turn that warn- 
ing into an error. 


SHORT-CIRCUIT CONDITIONAL A conditional operator that evaluates its second 
operand only when necessary. In Standard ML, the short-circuit condition- 
als are andalso and orelse. Keyword and, which looks like it should be a 
conditional, actually means mutual recursion. Thanks, Professor Milner. 


TYPE ABBREVIATION An abbreviation for a type, defined with keyword type. May 
take one or more TYPE VARIABLES as parameters. When there are no type 
parameters, a type abbreviation acts just like C’s typedef. 


TYPE VARIABLE In ML, a name that begins with a quote mark, like 'a. Stands for 
an unknown type. When used in an ML type, a type variable makes the type 
POLYMORPHIC. 


VALUE CONSTRUCTOR A name that either constitutes a value of ALGEBRAIC DATA 
TYPE, like nil or NONE, or that produces a value of algebraic data type when 
applied to a value or a tuple of values, like :: or SOME. 


5.7.2 Further reading 


To learn Standard ML, you have several good choices. The most comprehensive 
published book is by Paulson (1996), but it may be more than you need. The much 
shorter book by Felleisen and Friedman (1997) introduces ML using an idiosyn- 
cratic, dialectical style. If you can learn from that style, the information is good. 
If you are a proficient C programmer, you might like the book by Ullman (1997). 
This book has helped many C programmers make a transition to ML, but it also has 
a problem: the ML that it teaches is far from idiomatic. 

There are also several good unpublished resources. Harper’s (1986) introduc- 
tion is short, sweet, and easy to follow, but it is for an older version of Standard ML. 
More recently, Harper (2011) has released an unfinished textbook on programming 
in Standard ML; it is up to date with the language, but the style is less congenial to 
beginners. Tofte (2009) presents “tips” on Standard ML, which I characterize as a 
20-page quick-reference card. You probably can’t get by on the “tips” alone, but 
when you are working at the computer, they are useful. 


5.8 EXERCISES 


The exercises are summarized in Table 5.3 on page 321. The highlights encourage 
you to extend or improve pScheme: 


* In Exercise 2, you extend Scheme so a function can take an unbounded 
number of arguments. 


* In Exercise 6, you develop a different technique for using ML functions as 
pScheme primitives: instead of applying functions to the ML functions, you 
compose each ML function with an embedding function and a projection 
function. It’s a very type-oriented way of building an interpreter. 


* In Exercise 10, you use facts about free variables to change the representation 
of closures, and you measure to see if the change matters. 


Exercises 2 and 10 are very satisfying. 


Table 5.3: Synopsis of all the exercises, with most relevant sections 


Exercises Sections 


Notes 


land 2 5.2, 5.3 
3 to 6 5.3, 5.4 
7 and 8 1.7, 5.2 


9and10 5.6 


Working with syntax and semantics: add cond, support 

variadic functions. 

LScheme closures represented as ML functions; embedding 

and projection functions. 

Derivations of operational semantics represented as ML §5.8 
data structures. Exercises 
Prove that closures use only free variables, and use that 
proof to improve the implementation (§5.3). 
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5.8.1 Retrieval practice and other short questions 


Ao oO 


What’s one way to produce an ML value of type name * int? 
What ML values inhabit the type (name * int) list? 

In type 'a env, what can the 'a stand for? 

What are [] and ::? How are they pronounced? 


In ML, any two-argument function can be defined as infix. Functions + and * 


you know. What do functions @ and 4 do? 


F. From function bind, what species of value is produced by the ML expression 
(name, v) :: rho? 


G. What Scheme definition form corresponds to ML’s fun? 


H. Why is ML’s definition of find split into two clauses? How does the ML evalu- 
ator decide which clause to execute? What does each clause do? 


I. During evaluation, what would cause exception BindListLength to be raised? 


J. In this chapter, what’s the object language and what’s the metalanguage? 


K. Can an ML value of type int always be embedded into a psScheme value? If so, 
how? If not, why not? 


L. Cana Scheme value always be projected into an ML value of type int? If so, 
how? If not, why not? 


M. Can an ML function of type int * int -> int always be embedded into a 
pScheme primitive of type exp * value list -> value? If so, how? If not, 


why not? 


N. Suppose you want to change the semantics of zScheme so that in if expres- 
sions and while loops, the number zero is treated as falsehood, as in JavaScript. 
What interpreter code do you change and how? 


O. In chunk (apply closure clo to args 310c), explain what bindList constructs 


and why. 


ome) 


In expression (lambda (n) (+ 1n)), what names are free? 
In expression (lambda (x) (f (g x))), what names are free? 
In expression (lambda (f g) (lambda (x) (f (g x)))), what names are free? 


Besides lambda, what other syntactic form of expression can introduce new 


names that are bound in that expression? 
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5.8.2 Working with syntax and semantics 


1. 


Syntactic sugar for cond. Section 2.13.2 (page 163) describes syntactic sugar 
for Lisp’s original conditional expression: the cond form. Add a cond form to 
pScheme. Start with this code: 


322. (rows added to ML puScheme’s exptab1e in exercises [prototype] 322)= 


, ((cond ([q a] ...))", desugarCond : (exp * exp) list -> exp 


let fun desugarCond qas = raise LeftAsExercise "desugar cond" 
val qa = bracket ("[question answer]", pair <$> exp <*> exp) 

in desugarCond <$> many ga 

end 


) 


Variadic functions. Extend pScheme to support functions with a variable 
number of arguments. Do so by giving the name ... (three dots) special 
significance when it appears as the last formal parameter in a lambda. For 
example: 


-> (val f (lambda (x y ...)) (+ x (+ y (foldl + 0 ...))) 
-> (f 12345) ; in f, rho = § x |-> 1, y |-> 2, ... |-> '(3 4 5) 3 
15 


In this example, if f gets fewer than two arguments, it is a checked run-time 
error. If f gets at least two arguments, any additional arguments are placed 
into an ordinary list, and the list is used to initialize the location of the formal 
parameteter associated with .... 


(a) Implement this new feature. Begin by changing the definition of 
lambda on page 306 to 


and lambda = name list * { varargs : bool 3 * exp 


Now recompile; type-error messages will tell you what other code you 
have to change. 


For the parser, you may find the following function useful: 
fun newLambda (formals, body) = 
case reverse formals 
of "..." :: fs' => LAMBDA (reverse fs', {varargs=true?, 
body) 
fi, 32 => LAMBDA (formals, {varargs=falsez, body) 
This function has type 


name list * exp -> name list *  varargs : bool 3 * exp, 


and it is designed for you to adapt old syntax to new syntax; just drop it 
into the parser wherever LAMBDA is used. 


(b) As acomplement to the varargs lambda, write a new apply primitive 
such that 


(apply f '(12 3)) 
is equivalent to 
(F123) 


Sadly, you can’t use PRIMITIVE for this; you'll have to invent a new kind 
of thing that has access to the internal eval. 


(c) Demonstrate these utilities by writing a higher-order puScheme func- 
tion cons-logger that counts cons calls in a private variable. It should 
operate as follows: 


-> (val cl (cons-logger)) 

-> (val log-cons (car cl)) 

-> (val conses-logged (cdr cl)) 
-> (conses-logged) 


-> (log-cons f el e2 ... en) ; returns (f e1 e2 ... en), 
; incrementing private counter 
; whenever cons is called 
-> (conses-logged) 
99 ; or whatever else is the number of times cons is called 
; during the call to log-cons 


(d) Rewrite the APPLYCLOSURE rule (page 316) to account for the new ab- 
stract syntax and behavior. 


5.8.3 Higher-order functions, embedding, and projection 


3. pScheme closures represented as ML functions. Change the evaluation of lambda 
expressions so that evaluating a LAMBDA produces an ML function of type 
exp * value list -> value. (The exp parameter should be ignored.) That’s 
the same type as a primitive function, so with this change, evaluating a 
LAMBDA can produce a PRIMITIVE, nota CLOSURE. On the strength of this trick, 
rename PRIMITIVE to FUNCTION, and eliminate CLOSURE from the interpreter. 


Identify the advantages of this simplification. Identify the drawbacks. 
4. Embedding and projection for lists. 


(a) Define function projectList of type value -> value list. If projec- 
tion fails, projectList should raise the RuntimeError exception. 


(b) Rewrite function embedList to use foldr. 


5. Reusable embedding for integer functions. In Section 5.4, functions arithOp and 
comparison use the same code fragment for embedding functions that con- 
sume integers. Break this embedding out into its own function, intBinary 
of type (int * int -> 'a) -> (value * value -> 'a). Rewrite arithOp and 
comparison to use intBinary. 


6. Embedding by composing first-order functions. In Section 5.4 (page 312), the 
primitive functions are defined by applying higher-order embedding func- 
tions to ML primitives. In this exercise, you instead compose the ML primi- 
tives on the right with first-order projection functions and on the left with 
first-order embedding functions. Embedding functions should be total; 
that is, application of an embedding function should always succeed. But 
projection functions can be partial; application of a projection function can 
fail, in which case it should raise RuntimeError. 


(a) Define a projection function of type value list -> value * value and 
another of type value list —> value. 
(b) Define a projection function of type value * value —> int * int 


(c) Find an embedding function of type int -> value, or if you can’t find 
one, define one. 
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(d) Find an embedding function of type bool -> value, or if you can’t find 
one, define one. 


(e) Using your embedding and projection functions, redefine the jsScheme 
primitives using function composition. For example, define uScheme’s 
cons by composing ML’s PAIR on the right with projection functions and 
on the left with embedding functions. 

For any primitive, the projections used on its right should depend only 
on its argument type, and the embeddings used on its left should de- 
pend only on its result type. 


Continue to use inExp to build initialBasis. 


5.8.4 Proofs as data 


7. Representation of judgments and derivations in ML. 


(a) Devise a representation, in Standard ML, of the judgments of the oper- 
ational semantics for wScheme. 


(b) Devise a representation, in Standard ML, of derivations that use the op- 
erational semantics of Scheme. 


(c) Change the eval function of the ~Scheme interpreter to return a deriva- 


tion instead of a value. 


You may wish to revisit the material on proofs and derivations in Section 1.7 
(page 55). 


. Validity of derivations. Using the representation of derivations in item 7(b), 


write a proof checker that tells whether a given tree represents a valid deriva- 
tion. 


5.8.5 Free variables 


9. Proof: A closure needs only the free variables of its code part. In this exercise, 


you prove that the evaluation of an expression doesn't depend on arbitrary 
bindings in the environment, but only on the bindings of the expression’s 
free variables. 


If X is a set of variables, we can ask what happens to an environment p if we 
remove the bindings of all the names that are not in the set _X. The modified 
environment is written | x» and itis called the restriction of p to X.. You will 
prove, by structural induction on derivations, that if (e, p,0) |) (v,c), then 
(e, Plevtey? a) {)} (v,o). (This theorem also justifies the syntactic sugar for 
short-circuit | | described in Section 2.13.3 on page 164. And itis related toa 
similar theorem from Exercise 52 on page 195 in Chapter 2.) 


To structure the proof, I recommend you introduce a definition and a lemma. 


* To account of the idea of “extra” or “unneeded” variables, define the 
relation p CE p’ (pronounced “p’ extends p” or “p’ refines p”). It means 
that the domain of p’ contains the domain of p, and on their common 
domain, they agree: dom p C dom p’ andVz € dom p: p(x) = p'(x). 


* Prove this lemma: If X C X’ C doma, then pl x CL ree LC p. 


10. 


These tools are useful because except for LET forms and LAMBDA expres- 
sions, if an expression e has a subexpression e;, then fv(e;) C fv(e). 


Now prove, by structural induction on derivations, that if (e, p,o) |) (v,o), 
then (e, Plevtey? a) |) (v,o). A reasonable induction hypothesis might be 


that if that if (e, p,o) 4) (v,o), andif p fv(e) E p’, then (e, p’,c) J) (vu, 0). 


Smaller closures and their performance. The result proved in Exercise 9 can be 
used to optimize code. In chunk 310a, a LAMBDA expression is evaluated by 
capturing a full environment p. 


(a) 


(b) 


Modify the code to capture a restricted environment that contains only 
the free variables of the LAMBDA expression. That is, instead of allo- 
cating the closure (LAMBDA((x1,...,2n),€),¢)), allocate the smaller 
closure (LAMBDA((z1,.-.,n),€), P| ), where the set X is defined 
by X = fv(LAMBDA((%1,.-..,2n),€)). 


Measure the modified interpreter to see if the optimization makes a dif- 
ference. As a sufficiently long-running computation, you could try a 
quadratic sort of a very long list, or an exponential count of the num- 
ber of distinct subsequences of an integer sequence that sum to zero. 
Or you could run a computation using the metacircular evaluator in 
Section E.1. 
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checking is lost. We suggest that a solution to this problem 
is to permit types themselves to be passed as a special 

kind of parameter, whose usage is restricted in a way 
which permits the syntactic checking of type correctness. 


John Reynolds, Towards a Theory of Type Structure 


The real success of a formal technique is 
when it is used ubiquitously without the 
designer being aware of it (e.g., type systems). 


Arvind, IFIP Working Group 2.8, June 17, 2008 


The languages of the preceding chapters, Impcore and Scheme, are dynamically 
typed, which is to say that many faults, such as applying a function to the wrong 
number of arguments, adding non-numbers, or applying car to a symbol, are not 
detected until run time. Dynamically typed languages are very flexible, but on any 
given execution, a fault might surprise you; even a simple mistake like typing cdr 
when you meant car might not have been detected on previous runs. And using 
cdr instead of car doesn’t cause a fault right away: cdr simply returns a list in a 
context where you were expecting an element. But if, for example, you then try to 
add 1 to the result of applying cdr, that is a checked run-time error: adding 1 to a list 
instead of a number. To rule out such errors at compile time, without having to run 
the faulty code, a programming language can use static typing. 

Static typing is implemented by a compile-time analysis, which decides if the 
analyzed code is OK to run. All such analyses build on the same two approaches: 
type checking and type inference. In type checking, every variable and formal param- 
eter is annotated with a type, which restricts the values that the variable or parame- 
ter may have at run time. Type checking is used in such languages as Ada, Algol, C, 
C++, Go, Java, Modula-3, Pascal, and Rust. In type inference, also called type recon- 
struction, variables and parameters need not be annotated; instead, each variable 
or parameter is given a type by an algorithm, which looks at how the variable or 
parameter is used—the types are reconstructed from the code. Type inference is 
used in such languages as Haskell, Hope, Miranda, OCaml, Standard ML, and Type- 
Script. In both approaches, the decision about whether it is OK to run a program is 
made according to the rules of a language-dependent type system. 

Effective types do much more than just rule out programs that might commit 
run-time errors; types also act as documentation—the more expressive the type 
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system, the better the documentation. In a truly expressive system, the name and 
type of a function often suffice to show what the function is supposed to do. 

Type systems, type checking, and type inference can be used in many ways. 
One of the most effective uses is to help guarantee safety. In a safe language, mean- 
ingless operations (adding non-numbers, dereferencing a null pointer, and so on) 
are either ruled out or are detected and reported. Although safety can be guaran- 
teed by checking every operation at run time—as in Impcore, jsScheme, and full 
Scheme—a good static type system performs most checks at compile time. A sim- 
ple static type system can guarantee properties like these: 


* Numbers are added only to numbers. 
+ Every function receives the correct number of arguments. 
* Only Booleans are used in if expressions. 


* Primitives car and cdr are applied only to lists. 


When these properties are guaranteed, potentially meaningless operations are re- 
ported to the programmer right away, before a program is shipped to its users. And 
the implementations of addition, function call, and if don’t have to check their 
operands at run time. 

To guarantee safety, a type system must be crafted such that if it accepts a pro- 
gram, its rules guarantee that no meaningless operations can be executed. The 
guarantee is established by a type-soundness theorem, an idea so popular that it has 
its own slogan: “well-typed programs don’t go wrong.” The slogan is lovely, but not 
a cure-all; “going wrong” has a precise, technical meaning, which is usually nar- 
row. For example, “going wrong” does not typically include unwanted behaviors 
like these: 


« A number is divided by zero. 
* The car or cdr primitive is applied to an empty list. 


« A reference to an element of an array falls outside the bounds of that array. 


These misbehaviors can be ruled out by a static type analysis, but the types get com- 
plicated, so they often aren't. Most general-purpose languages keep their types 
simple, and they guarantee safety by supplementing the static type system with 
run-time checks for errors like division by zero or array access out of bounds. 

A safe language shouldn’t put the programmer in a straitjacket. When a type 
system is overly restrictive, programmers complain, often using slang terms like 
“strong typing.” And restrictive type systems can make it hard to reuse code. For ex- 
ample, Pascal’s type system notoriously made it impossible to write a function ca- 
pable of sorting arrays of different lengths. As another example, in Chapters 1 and 2, 
C’s type system requires a distinct set of list functions for each possible list type, 
even though the functions defined on different types have identical bodies. Such 
duplication can be avoided, while maintaining safety and type checking, by using a 
polymorphic type system, like the one described in Section 6.6 of this chapter. Poly- 
morphic type systems provide abstractions that can be parameterized by types; one 
example of such an abstraction is the C++ template. 

Or restrictions can be dodged by using unsafe language features, like casts to 
and from void * in C. Unsafe features are useful in situations like these: 


* You want to write a program that manipulates memory directly, like a device 
driver or a garbage collector. Such a program would ideally be safe, but how 
best to make such a thing safe—say, by combining a sophisticated type system 
with a formal proof of correctness—is a topic of ongoing research. 


* You want a relatively simple type system and you don’t want to pay overhead 
for run-time checks. For example, you like the simplicity of C, and you love 


that casting a pointer from one type to another costs nothing. And although 
casts are unsafe in general, you’ve convinced yourself that yours are safe. 


Even in a language with unsafe features, static typing is useful: types document the 
code, and they can prevent many run-time errors, even if a few slip through. The 
ones that slip through are called unchecked run-time errors—it’s those errors that 
make a language unsafe. The best designs allow unsafe features only in limited 
contexts; to see this done well, study Modula-3 (Nelson 1991). 


Type systems are highly developed, and in the next four chapters you will learn 
how they work and how to use them effectively. In this chapter, you will learn about 
type systems and type checking. You will study not one language but two: Typed 
Impcore and Typed psScheme. Typed Impcore is straightforward; it models the re- 
strictive type systems of such languages as Pascal and C. Typed Impcore introduces 
type systems and serves as an uncomfortably restrictive example. Typed Scheme 
is more ambitious; although its design starts from Scheme, it ends up requiring 
so many type annotations it feels very different. Typed jsScheme introduces poly- 
morphism and serves as an eye-opening example. 

Typed ysScheme is powerful, but its explicit annotations make it unpleasant 
to write. This unpleasantness is relieved by the more advanced type systems de- 
scribed in Chapters 7 to 9. Chapter 7 describes nano-ML. Nano-ML eliminates an- 
notations, and yet it provides most of the polymorphism that Typed Scheme en- 
joys. It does so by using the Hindley-Milner type system, which defines a form of poly- 
morphism that can be inferred. The Hindley-Milner type system forms the core 
of many of today’s innovative, statically typed languages, including Standard ML, 
Haskell, OCaml, Agda, Idris, and many others. It works most effectively when cou- 
pled with user-defined algebraic data types, which are the main idea of Chapter 8. 

Chapter 9 presents a different alternative to Typed puScheme: Molecule. Like 
Typed uScheme, Molecule uses annotations, but the annotations that direct poly- 
morphism are applied to entire modules, not to individual functions. The resulting 
language provides the explicit control you get with Typed Scheme, without the 
notational burden. 


6.1 TYPED IMPCORE: A STATICALLY TYPED IMPERATIVE CORE 


A type system finds errors that might otherwise be hard to detect. (A type system 
may also help determine how values are represented and where variables can be 
stored, but such topics are beyond the scope of this book.) A type system worth 
studying should therefore be coupled with a language that provides ample opportu- 
nities to commit detectable errors—and that is simple enough to learn easily. Imp- 
core is suitably simple, but the only readily detectable error is to pass the wrong 
number of arguments to a function. To create a few more opportunities for de- 
tectable errors, I have designed Typed Impcore: 


« A value may be an integer, a Boolean, an array of values, or unit (page 334). 
Now you can try to use the wrong species of value. 


+ Every variable and expression must have a typethat is known at compile time. 
The types of some variables, such as the formal parameters of functions, are 
written down explicitly, much as they are in C and Java. Precise, formal rules 
determine whether an expression has a type and what the type is. 


* The typing rules are implemented by a type checker. The type checker per- 
mits a definition to be evaluated only if all its expressions have types. The 
type checker I present in this chapter checks only integer and Boolean types; 
extending it to check arrays is left to you (Exercise 18). 
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def = exp 

(use file-name) 

(val variable-name exp) 

(define type function-name (formals) exp) 
unit-test 


unit-test ::= (check-expect exp exp) 

(check-assert exp) 

(check-error exp) 

(check-type-error def) 

(check-function-type function ({ type} -> type)) 


exp ::= literal 

variable-name 

(set variable-name exp) 
(if exp exp exp) 

(while exp exp) 

(begin {exp}) 
(function-name { exp} ) 


formals ::= { [variable-name : type] } 
type n= int | bool | unit | (array type) 
literal = ::= numeral 


Figure 6.1: Concrete syntax of Typed Impcore 


* Impcore’s type system is sound (Exercise 26), which means informally that in 
every execution, at every point in the program, when an expression produces 
a value, that value is consistent with the expression’s type. Type soundness 
ensures that if a program passes the type checker, it does not suffer from type 
errors at run time. 


Typed Impcore is presented in two stages: first the integer and Boolean parts, then 
(Section 6.3) arrays. 


6.1.1 Concrete syntax of Typed Impcore 


Typed Impcore has the concrete syntax shown in Figure 6.1. Unlike untyped Imp- 
core, Typed Impcore requires that the argument and result types of functions be 
declared explicitly. Types are written using new syntax; in addition to Impcore’s 
definitions (def) and expressions (exp), Typed Impcore includes a syntactic cate- 
gory of types (type). 
Explicit types are needed only in function definitions: 

330. (transcript 330) = 33lap 

-> (define int addi ([n : int]) (+n 1)) 

addi : (int -> int) 

-> (addi 4) 

5s int 

-> (define int double ([n : int]) (+n n)) 

double : (int -> int) 

-> (double 4) 

8 : int 


Types provide good documentation, and to document a function’s type in a 
testable way, Typed Impcore adds a new unit-test form, check-function-type: 
331a. (transcript 330) += 1330 331b> 

-> (check-function-type add1 (int -> int)) 
-> (check-function-type double (int -> int)) 

Because unit tests are not run until the end of a file, a function’s type test can— 
and should—be placed before its definition. 
331b. (transcript 330) += <1331a 331¢> 

-> (check-function-type positive? (int -> bool)) 
-> (define bool positive? ([n : int]) (> n 0)) 

Unlike C, Typed Impcore accepts only Boolean conditions: 

331c. (transcript 330) += <1331b 344aD 
-> (if 1 77 88) 
type error: Condition in if expression has type int, which should be bool 
-> (if (positive? 1) 77 99) 
77: : int 


6.1.2 Predefined functions of Typed Impcore 


The predefined functions of Typed Impcore do the same work at run time as their 
counterparts in Chapter 1, but because they include explicit types for arguments 
and results, their definitions look different. And because Typed Impcore has no 
Boolean literals, falsehood is written as (= 1 0), and truth as (= 00). 
331d. (predefined Typed Impcore functions 331d) = 331e> 

(define bool and ([b : bool] [c : bool]) (if bc b)) 

(define bool or ([b : bool] [c : bool]) (if b b c)) 

(define bool not ([b : bool]) (if b (= 1 0) (= 0 0))) 

The comparison functions accept integers and return Booleans. 

331e. (predefined Typed Impcore functions 331d) += 331d 

(define bool <= ([m : int] [n : int]) (not (> m n))) 

(define bool >= ([m : int] [n : int]) (not (< mn))) 

(define bool != ([m : int] [n : int]) (not (= m n))) 


Functions mod and negated are defined in the Supplement. 


6.1.3 Types, values, and abstract syntax of Typed Impcore 


As in Chapter 5, the abstract syntax of Typed Impcore is defined by the represen- 
tation used in the implementation. The abstract syntax for a type (ty) is also the 
internal representation of a type. The internal representation of a function type 
(funty) is also the abstract syntax used in check-function-type. 
331f. (types for Typed Impcore 331f)= (S391a) 332a> 
datatype ty = INTTY | BOOLTY | UNITTY | ARRAYTY of ty 
datatype funty = FUNTY of ty list * ty 


A funty describes just one type; for example, FUNTY ([INTTY, INTTY], BOOLTY) 
describes the type of a function that takes two integer arguments and returns a 
Boolean result. In Typed Impcore, a function or variable has at most one type, 
which makes Typed Impcore monomorphic. 

Types are printed with the help of functions typeString and funtyString, 
which are defined in Appendix P. 
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Types are checked for equality by mutually recursive functions eqType and 
eqTypes: 


332a. (types for Typed Impcore 331f) += (S391a) <1331f 332b> 
eqlype : ty * ty -> bool 
eqlypes : ty list * ty list -> bool 

fun eqType (INTTY, INTTY) = true 

| eqType (BOOLTY, BOOLTY) = true 

| eqType (UNITTY, UNITTY) = true 

| eqType (ARRAYTY ti, ARRAYTY t2) = eqType (ti, t2) 
| eqType (_, _) = false 


and eqlypes (tsi, ts2) = ListPair.allEq eqType (ts1, ts2) 

Types should always be checked for equality using eqType, not the built-in = oper- 

ator. As shown in Section 6.6.6 below, a single type can sometimes have multiple 

representations, which = reports as different but should actually be considered the 

same. Using eqType gets these cases right; if you use =, you risk introducing bugs 

that will be hard to find. 

Function types are checked for equality using function eqFunty. 

332b. (types for Typed Impcore 331f) += (S391a) <1332a 

| eqFunty : funty * funty -> bool 


fun eqFunty (FUNTY (args, result), FUNTY (args', result')) = 
eqlypes (args, args') andalso eqType (result, result') 


Moving to run time, there are only two forms of value. Values of integer, 
Boolean, or unit type are represented using the NUM form; values of array types 
are represented using the ARRAY form. 
332c. (definitions of exp and value for Typed Impcore 332c)= (S391b) 332d > 

datatype value = NUM-~ of int 
| ARRAY of value array 


And finally the syntax. Typed Impcore includes every form of expression found 
in untyped Impcore, plus new forms for equality, printing, and array operations. 


332d. (definitions of exp and value for Typed Impcore 332c) += (S391b) <1332c 
datatype exp LITERAL of value 
VAR of name 
SET of name * exp 
IFX of exp * exp * exp 


| 
| 
| 
| WHILEX of exp * exp 

| BEGIN of exp list 

| APPLY of name * exp list 

(Typed Impcore syntax for equality and printing 332e) 

(array extensions to Typed Impcore’s abstract syntax 344d) 

In Typed Impcore, the =, print, and println operations cannot be imple- 
mented by primitive functions, because they operate on values of more than one 
type: they are polymorphic. In a monomorphic language like Typed Impcore or C, 
each polymorphic primitive needs its own syntax. 
332e. (Typed Impcore syntax for equality and printing 332e)= (332d) 

| EQ of exp * exp 
| PRINTLN of exp 
| PRINT of exp 


Similarly, as described in Section 6.3.2 below, Typed Impcore’s array operations 
also need special-purpose syntax. Such special-purpose syntax is typical; in many 
languages, array syntax is written using square brackets. As another example, 
a pointer in C is dereferenced by a syntactic form written with * or ->. 


In Typed Impcore, the syntax for a function definition includes explicit param- 
eter types and an explicit result type. As is customary in formal semantics and in 
Pascal-like and ML-like languages, but not in C, the syntax places a formal param- 
eter’s type to the right of its name. 


333a. (definition of def for Typed Impcore 333a) = (S391b) 
type userfun = ~ formals : (name * ty) list, body : exp, returns : ty 3? 86.1 
= * 
datatype def i name exp Typed Impcore: 
! wanes A statically typed 


DEFINE of name * userfun F : 
imperative core 


Typed Impcore’s unit tests include check-expect and check-error from un- 
typed Impcore and jsScheme, plus two new unit tests related to types: 333 
333b. (definition of unit_test for Typed Impcore 333b) = (S391b) 

datatype unit_test = CHECK_EXPECT of exp * exp 
| CHECK_ASSERT of exp 
| CHECK_ERROR of exp 
| CHECK_TYPE_ERROR of def 
| CHECK_FUNCTION_TYPE of name * funty 


In Typed Impcore, asin Impcore, a function is not an ordinary value. A function 
takes one of two forms: USERDEF, which represents a user-defined function, and 
PRIMITIVE, which represents a primitive function. Because the type system rules 
out most errors in primitive operations, primitive functions are represented more 
simply than in Chapter 5: in Typed Impcore, a primitive function is represented by 
an ML function of type value list -> value; there is no parameter of type exp. 
333c. (definition of type func, to represent a Typed Impcore function 333c)= (S391b) 

datatype func = USERDEF of name list * exp 
| PRIMITIVE of value list -> value 


A func contains no types; types are needed only during type checking, and the func 
representation is used at run time, after all types have been checked. 


6.1.4 Type system for Typed Impcore 


By design, Typed Impcore’s static type system is more restrictive than Impcore’s 
dynamic type system. For example, because the static type system distinguishes 
integers from Booleans, it prevents you from using an integer to control an if ex- 
pression. This restriction should not burden you overmuch; if you have an integer i 
that you wish to treat as a Boolean, simply write (!= 10). Similarly, if you have a 


Boolean b that you wish to treat as an integer, write (if b 10). Typed Impcore also ARRAYTY 331f 
prevents you from assigning the result of a while loop to an integer variable—which BOOLTY 331f 
there is no good reason to do, because the result is always zero. CUNY: te 
Typed Impcore accepts a definition only if its expressions, also called terms, enone a31f 
have types. Which terms have types is determined by a formal proof system (the type name 303 
type system), which is related to the formal proof system that determines which type ty 331f 


terms have values (the operational semantics). To refer to a type, the type sys- ea eh) 


tem uses a metavariable formed with the Greek letter 7 (pronounced “tau,” which 
rhymes with “wow”). And to remember the type of a variable or function, the type 
system uses a metavariable formed with the Greek letter I (pronounced “gamma’”). 
Typed Impcore’s type system relates these elements: simple types, which are 
written 7; three base types, which are written INT, BOOL, and UNIT; one type con- 
structor, which is written ARRAY; many function types, which are written Ts; and 
three type environments, which are written Ig, I'y, and I’,. The type environments 
give the types of global variables, functions, and formal parameters, respectively. 
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A simple type is a base type or the array constructor applied to a simple type.! 
Because each type in Typed Impcore requires its own special-purpose abstract syn- 
tax, I write the names using the SMALL CAPs font, which I conventionally use for 
abstract syntax. 


T := INT|BOOL | UNIT | ARRAY(T) 
The type of a function is formed from argument types 7, to T,, and result type T. 
ThUS= TT] X60 X TST 


Just as functions are not values, function types are not value types. 

The integer, Boolean, and array types describe values that represent integers, 
Booleans, and arrays. The unit type plays a more subtle role; its purpose is to be dif- 
ferent from the others. It is the type we give to an expression that is executed purely 
for its side effect and does not produce an interesting value—like a while loop or 
println expression. In most typed languages, an operation that is executed only 
for side effects is described by a special type. In C, C++, and Java, this type is called 
void, because the type is uninhabited, i.e., there are no values of type void. In the 
functional language ML, the special type is called unit, because the unit type has 
exactly one inhabitant. For Typed Impcore, the unit type is more appropriate than 
void, because in Typed Impcore, every terminating evaluation produces a value. 

In ML, the inhabitant of the unit type is the empty tuple, which is written (). 
Its value is uninteresting: every expression of type unit produces the same empty 
tuple, unless its evaluation fails to terminate or raises an exception. In Typed Imp- 
core, the inhabitant of the unit type is the value 0—but as long as the type system 
is designed and implemented correctly, no Typed Impcore program can tell what 
the inhabitant is. 


6.1.5 Typing rules for Typed Impcore 


A type system is written using the same kind of formal rules we use to write oper- 
ational semantics; only the forms of the judgments are different. Where the judg- 
ments in an operational semantics determine when an expression is evaluated to 
produce a value, the judgments in a type system determine when an expression 
has a type. The judgments of a type system and the judgments of the correspond- 
ing operational semantics are closely related (Exercise 26). 


Type-formation rules 


A type system usually begins with rules that say what is and isn’t a type. Typed 
Impcore’s types are so simple that rules aren't really necessary; the tiny grammar 
for 7 above tells the story. But the judgment form for Typed Impcore is 
and the rules are as follows: 


(UNITTYPE) (INTTYPE) (BOOLTYPE) 
ae BEE a eee mats wa ee. 
UNIT 1s a type INT 1s atype BOOL 1s a type 
Tisatype 
YP (ARRAYTYPE) 


ARRAY(T) isa type. 


In the interpreter, every value of type ty (chunk 331f) is a type. 


lIn other words, types are defined by induction, and the base types are the base cases. In Typed 
Impcore, the type of an array does not include the array’s size. 


Typing judgment for expressions 


The typing judgment for expressions is |I'¢,[y,[, / e: T |, meaning that given 


type environments I’;, 'y, I',, expression e has type T. Judgments of this form are 
proved by the rules of Typed Impcore’s type system. These rules are deterministic, 
and in a well-typed Typed Impcore program, every expression has exactly one type. 
In other words, given the environments I’;, 4, I, and the abstract-syntax tree e, 
there is at most one 7 such that '¢,4,I', | e : r (Exercise 20). To find this 7, or 
to report an error if no such T exists, is the job of a type checker. 


Typing rules for expressions 


All literals are integers. This rule is sound because there are no Boolean literals in 
Typed Impcore: the parser creates only integer literals. 


LITERAL 
Te, 0y,0, - LITERAL(v) : INT ( ) 


A use of a variable is well typed if the variable is bound in the environment. As 
in Chapter 1, formals hide globals. 


x €doml, (FORMALVAR) 
Tz, P'g,T, F var(x) : T(z) 
cédoml, «€ dom (GLOBALVAR) 


Te, Tg, Tr, E VAR(x) : T'e(x) 

An assignment is well typed if the type of the right-hand side matches the type 

of the variable being assigned to. In other words, assigning to a variable mustn't 

change its type. And just as in the operational semantics, the rules consult two 
environments. 


xédoml, I,(4)=7 
Te,0¢,P pF e:7 


FORMALASSIGN 
Te, 0 g,D, F SET(x,e) : 7 
x¢édomT, «xeédomle I(x) =7 
T;,0g,0,r e: 
ieee eT, (GLOBALASSIGN) 


Deel gol gl SET a,c) or 


If the assignment is well typed, its type is the type of the variable and of the value 
assigned to it. An assignment could instead be given type unit, but this choice 
would rule out such expressions as (set x (set y 0)). In Typed Impcore, as in C, 
such expressions are permitted. 

A conditional expression is well typed if the condition is Boolean and the two 
branches have the same type. In that case, the type of the conditional expression 
is the type shared by the branches. 


Te, Pg,P, F e1 : BOOL Te, 0g, pF eg: 7 Ve, 0g,0, F e3 : 7 


IF 
Te, 0 ¢,T, - 1F(e1, €2,€3) 2 T Me) 


Unlike the rules for literals, variables, and assignment, the IF rule is structured 
differently from the IF rules in the operational semantics. The operational seman- 
tics has two rules: one corresponds to e; {} BOOLV(#t) and evaluates e2, and one 
corresponds to ce; |} BOOLV(#f) and evaluates e3. Each rule evaluates just two of 
the three subexpressions. The type system, which cares only about the type of €1, 
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not its value, needs only one rule, which checks the types of all three subexpres- 
sions. 

A WHILE loop is well typed if the condition is Boolean and the body is well typed. 
The 7 that is the type of the body eg is not used in the conclusion of the rule, because 
it matters only that type 7 exists, not what it is. 


Te, Pg, TP, F e1 : BOOL Te, 0g, , F eg : 7 
Te, 04,0, / WHILE(e1, €2) : UNIT 


(WHILE) 


As explained above, because a WHILE loop is executed for its side effect and does 
not produce a useful result, it is given the unit type. 

Like the IF rule, the WHILE rule is structured differently from the WHILE 
rules in the operational semantics. The operational semantics has two rules: one 
corresponds to e; |} BOOLV(#t) and iterates the loop, and one corresponds to 
€, {} BOOLV(#f) and terminates the loop. The type system needs only one rule, 
which checks both types. 

A BEGIN expression is well typed if all of its subexpressions are well typed. Be- 
cause every subexpression except the last is executed only for its side effect, it could 
legitimately be required to have type UNIT. But I want to allow SET expressions in- 
side BEGIN expressions, so I permit a subexpression in a BEGIN sequence to have 


any type. 
Te,0¢,P,F e1: 71 on Te,La, lp eae Tr 
Te, Pg, + BEGIN(€1,..-,€n) : Tr 


(BEGIN) 


The premises mentioning €1,...,€n—1 are necessary because although it doesn’t 
matter what the types of €,,...,€,_1 are, it does matter that they have types. 
An empty BEGIN is always well typed and has type UNIT. 


EMPTYBEGIN 
Te, 0y,P, / BEGIN() : UNIT ( ) 


A function application is well typed if the function is applied to the right num- 
ber and types of arguments. A function’s type is looked up in the function-type 
environment I'y. The type of the application is the result type of the function. 


lg(f) = +X MOT Te,Te,D,pFe:m%, 1<i<n 
Key ial, PAPPIS eisai eq )aF 


(APPLY) 


As is typical for a monomorphic language, each polymorphic operation has its 
own syntactic form and its own typing rule. An equality test is well typed if it tests 
two values of the same type. 


Te,0¢,Pp e1:7 Te, 0,0, e2:7 
Te, 0y,Pp F EQ(e1, 2) : BOOL 


(EQ) 


A print or print1n expression is well typed if its subexpression is well typed. 


Te,0e,P pF e:7 
Te, 0y,[, / PRINTLN(e) : UNIT 


(PRINTLN) 


Typing judgment and typing rules for definitions 


Like the corresponding rules of operational semantics, the typing rule for a defi- 
nition may produce type environments with new bindings. The judgment has the 


form | (d,V'e, 0's) + (C'¢,P%) , which says that when definition d is typed given 


type environments I’; and Ig, the new environments are lr. and we 


If a variable x has not been bound before, its VAL binding requires only that the 
right-hand side be well typed. The newly bound z takes the type of its right-hand 


side. 
Te,T¢,{}Fe:7 av ¢ dome 


(vaL(x,e),P'e,Pg) + (Teta > r},T 9) 
If x is already bound, the VAL binding acts like a SET. And just like a SET, the VAL 
must not change x’s type (Exercise 29). 


Te,Tg,{}F e:7 Te(x) =7 
(vaL(z, e), '¢, 0g) > (Le, U9) 


A top-level expression is checked, but it doesn’t change the type environments. 
(In untyped Impcore, the value of a top-level expression is bound to global vari- 
able it. But in Typed Impcore, the type of it can’t be allowed to change, lest the 
type system become unsound. So a top-level expression doesn’t create a binding.) 


Te, To, {} e:7 
(exP(e), Te, 0g) > (Te, Tg) 


A function definition updates the function environment. The definition gives 
the type 7; of each formal parameter x;, and the type 7 of the result. In an environ- 
ment where each x; has type 7;, the function’s body e must be well typed and have 
type T. In that case, function f is added to the type environment I’y with function 
type T, X +--+ X T, > T. Because f could be called recursively from e, f also goes 
into the type environment used to typecheck e. 


(NEWVAL) 


(OLDVAL) 


(Exp) 


T1,-++5Tn are types 
TR=TM XX mOT 
f ¢ dom Ty 
Te, Ta{f to te}, {21 T1,.--,2n 4 mb err 
(DEFINE() (004% Tigo 0032 Tapert) ybeskey—@ Les Eas = eh) 
(DEFINE) 
In addition to the typing judgment for e, the body of the function, this rule also uses 
well-formedness judgments for types 7; to T,,. In general, when a type appears in 
syntax, the rule for that syntax may need a premise saying the type is well formed. 
(The result type 7 here does not need such a premise, because when the judgment 
form ---- e: Tis derivable, 7 is guaranteed to be well formed; see Exercise 22.) 
A function can be redefined, but the redefinition may not change its type (Ex- 
ercise 29). 


T1,+++,Tn are types 
Tg(f) = X++X MOT 
Pel oy et het Te ee ay er, ee 
(DEFINE(f, ((@1 : T1,---,2n! Tm), €:7)), Ve, Ue) > Ve, Ty) 


(REDEFINE) 


6.2 A TYPE-CHECKING INTERPRETER FOR TYPED IMPCORE 


Typed Impcore is interpreted using the techniques used to interpret Scheme in 
Chapter 5, plus support for types: in addition to abstract syntax for expressions and 
definitions, I define abstract syntax for types, which is shown in the code chunk 
(types for Typed Impcore 331f). Because the type system is so simple, the abstract 
syntax can also serve as the internal representation of types. 

Types are checked by new functions typeof and typdef, which are invoked by 
the read-eval-print loop. The type checker I present handles only integer, Boolean, 
and unit types; array types are left for the exercises. 
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Table 6.2: Correspondence between Typed Impcore’s type system and code 


Type system Concept Interpreter 
d Definition def, xdef, or unit_test 
(pages 333, $214 and 333) 
e Expression exp (page 332) 
Cie f Name name (page 303) 
T Type ty (page 331) 
Te, T, Type environment ty env (pages 304 and 331) 
rs ee fay et 
(pages 304 and 331) 
Ve,0g,0,e:7 Typecheck e typeof(e, le, Pg, Py) = 
T, and often tye = T 
(page 338) 
(d,T¢,T) (Te, P%) Typecheck d typdef(d, Te, Tg) = 
Te’, Pay S) (page 341) 
x € dom Definedness find (2, I) terminates 


without raising an 
exception (page 305) 


T(x) Type lookup find (a, T’) (page 305) 
T{a+4 7} Binding bind (x, 7, I’) (page 305) 
Tf{a1 ],...,2n'> Tm} Binding bindlist ([71,...,2n], 


[T1, tee TH ' T) (page 305) 


6.2.1 Type checking 


Given an expression e and a collection of type environments I's, 'g, and I’, calling 
typeof(e,P¢,ly,I,) returns a type 7 such that P¢,0y,0, - e : 7. If no such 
type exists, typeof raises the TypeError exception (or possibly NotFound). Internal 
function ty computes the type of e using the environments passed to typeof. 


338a. (type checking for Typed Impcore 338a) = (S391a) 341b> 


typeof : exp * ty env * funty env * ty env -> ty 
ty : exp -> ty 


fun typeof (e, globals, functions, formals) = 
let (function ty, checks type of expression given l'¢, 4, Ip 338b) 
in tye 
end 
Just as eval implements the rules of operational semantics, ty implements the 
rules of the type system. Each rule is shown before the code that implements it. 
Every literal has type int. 


(LITERAL) 
Te,0y,Pp) F LITERAL(v) : INT 
338b. (function ty, checks type of expression given Ve, 4, lp 338b)= (338a) 339a> 
fun ty (LITERAL v) = INTTY 
Avariable x has a type if it is defined in environment I’, or Ig. 
x €domI, 
(FORMALVAR) 


Te, Tg,D, + var(z) : T,(2) 


c«¢domT, x¢€domIls 
Te, Tg, lr, E VAR(x) : T'e(x) 


If x is not found in either I’, or I'g, the type checker raises the NotFound exception. 


(GLOBALVAR) 


339a. (function ty, checks type of expression given lc, 4, Pp 338b) += (338a) <338b 339b> 
| ty (VAR x) = (find (x, formals) handle NotFound _ => find (x, globals)) 
Anassignment (set x e) has atype if both x and € have the same type, in which $6.2 
case the assignment has that type. A type-checking 
interpreter for 
xé€doml, I[,(#)=7 Typed Impcore 
Te,0g,T, e:7 
eel a (FORMALASSIGN) 339 
Te, Tg,D,  SET(x,e) 2 7 
x¢édoml, «wédomlzy Tele) =7 
Te,0g,l,Fe:7 
tle el (GLOBALASSIGN) 
Des gil’p SET GEye) Sr 
The types of both z and e are found by recursive calls to ty. 
339b. (function ty, checks type of expression given 'c,04,Tp 338b) +=  — (338a) <1 339a 339d> 


| ty (SET (x, e)) = 
let val tau_x = ty (VAR x) 
val tau_e = ty e 
in if eqType (tau_x, tau_e) then tau_x 
else (raise TypeError for an assignment 339c) 
end 


When z and ¢ have different types—a case not covered by the specification—ty is- 
sues an explanatory error message. Creating this message takes more work than 
checking the types. 


339¢. (raise TypeError for an assignment 339c)= (339b) 
raise TypeError ("Set variable "A x A" of type " A typeString tau_x A 
"to value of type " A typeString tau_e) 


A conditional has a type if its condition is Boolean and if both branches have 


? ; - BOOLTY 331f 

the same type—in which case the conditional has that type. yeeros 
Pe,0g,P,e,: Boon T¢,Py,P,Fe2:7 Ve, Vg,P,h e3:7 as hee 
Te, 0 ¢,D, - 1F(e1, €2,€3) 2 T find 305b 

type funty 331f 

Again, most of the code is devoted to error messages. IFX 332d 
339d. (function ty, checks type of expression given T'¢, 4, 1p 338b) += (338a) <339b 340a> eee ae 
| ty (IFX (et, e2, €3)) = NotFound 305b 

let val taul = ty el SET 332d 

val tau2 = ty e2 type ty 331f 
val tau3 = ty e3 TypeError §213c 
in if eqType (tau1, BOOLTY) then typeString S398e 

if eqlype (taue, tau3) then ae “cee 

taue 
else 


raise TypeError 
("In if expression, true branch has type " A 
typeString tau2 4 " but false branch has type " A 
typeString tau3) 

else 
raise TypeError 
("Condition in if expression has type " A typeString taui1 A 
"|, which should be " A typeString BOOLTY) 
end 


Awhile loop has a type if its condition is Boolean and if its body has a type—we 
don’t care what type. In that case the while loop has type unit. 
Te, U¢g,P, F e1 : BOOL Te,0¢,P,F e2: 7 
Te, 04,0,  WHILE(e1, €2) : UNIT 


(WHILE) 


340a. (function ty, checks type of expression given'¢,I'4,[p 338b) +=  — (338a) 339d 340b> 
| ty C(WHILEX (e1, e2)) = 
let val taul = ty el 
val taue = ty e2 
in if eqType (tau1, BOOLTY) then 
UNITTY 
else 
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raise TypeError ("Condition in while expression has type " A 
typeString taul 4 ", which should be " A 
typeString BOOLTY) 
end 
A begin has a type if all its subexpressions have types, in which case the begin 
has the type of its last subexpression. Or if there are no subexpressions, type unit. 


Ve,0y,P, e1: 7% ee Te, 3,0 pF €n = Tr 


BEGIN 
Te, 0g, + BEGIN(€1,...,€n) : Tr ( ) 
EMPTYBEGIN 
Te, 0g, PF, / BEGIN() : UNIT 
The implementation uses Standard ML basis function List.last. 
340b. (function ty, checks type of expression given Ve, 4, p 338b) += (338a) <1340a 340c> 


| ty (BEGIN es) = 
let val bodytypes = map ty es 
in List.last bodytypes handle Empty => UNITTY 
end 
An equality test (= e; e2) has a type if e; and e2 have the same type, in which 
case the equality test has type bool. 


Pela; le Fer er Te,0¢,P, e2:7 
Te, Tg,T,  EQ(e1, €2) : BOOL 


(EQ) 


The types of e; and e2 are computed using an ML trick: val binds the pair of names 
(tau1, tau2) to a pair of ML values. This trick has the same effect as the separate 
computations of tau1 and tau2 in the WHILEX case above, but it highlights the sim- 
ilarity of the two computations, and it uses scarce vertical space more effectively. 


340c. (function ty, checks type of expression givenT'¢, Cy, p 338b)+=  — (338a) <1340b 340d> 
| ty (EQ (e1, e2)) = 
let val (tau1, tau2) = (ty e1, ty e2) 
in if eqType (tau1, tau2) then 
BOOLTY 
else 
raise TypeError ("Equality sees values of different types " 4 
typeString taul 4 " and " A typeString taue2) 
end 


A print expression has a type if its subexpression is well typed, in which case 
its type is unit. 
Te,0e,P pF e:7 
Te, 0y,P, / PRINTLN(e) : UNIT 


(PRINTLN) 


340d. (function ty, checks type of expression given T'¢, C4, 1p 338b) += (338a) 1340c 34lap 
| ty (PRINTLN e) = (ty e; UNITTY) 
| ty (PRINT e) = (ty e; UNITTY) 


A function application has a type if its function is defined in environment Ig, 
and if the function is applied to the right number and types of arguments. In that 
case, the type of the application is the result type of the function type found in Tg. 


Tg(f) = X +++ X OT Te,0g,P,Fe:m%, 1<icn 


APPLY 
Te, Pg,D, - APPLY(f,€1,...,€n) 27 ( ) 


If the function is applied to the wrong number or types of arguments, function 
badParameter, which is defined in the Supplement, finds one bad parameter and 
builds an error message. 

341a. (function ty, checks type of expression given Te, 14, Up 338b) += (338a) <1340d 


| ty (APPLY (f, actuals)) = badParameter : int * ty list * ty list -> 'a 


let val actualtypes map ty actuals 
val FUNTY (formaltypes, resulttype) = find (f, functions) 
(definition of badParameter $392b) 
in if eqTypes (actualtypes, formaltypes) then 
resulttype 
else 
badParameter (1, actualtypes, formaltypes) 
end 


6.2.2 Typechecking definitions 


The typing judgment for a definition d has the form (d, Te, y) + (Tj, ¢). This 
judgment is implemented by a static analysis that I call typing the definition. Calling 
typdef (d, Iz, ['g) returns a triple (l%., ly, 8), where s is a string describing 
a type. 

341b. (type checking for Typed Impcore 338a) += (S391a) <1338a 
typdef : def * ty env * funty env -> ty env * funty env * string 


fun typdef (d, globals, functions) = 
case d 
of (cases for typing definitions in Typed Impcore 341c) 
Each case of typdef implements one syntactic form of definition d. The first 
form is a variable definition, which may change a variable’s value but not its type. 
Depending on whether the variable is already defined, there are two rules. 


Te,T¢,{}F+e:7 av ¢domle 


NEWVAL 
Wax(x,e),Te,Ps) > Pela r},Pe) rer 
Te, 0 Fe: T a 
(vaL(z,e), Te, 0 ¢) > (Pe, P 4) 
Which rule applies depends on whether x is already defined. 
341c. (cases for typing definitions in Typed Impcore 341c)= (341b) 342b> 


VAL (x, @) => 
if not (isbound (x, globals)) then 
let val tau. = typeof (e, globals, functions, emptyEnv) 
in (bind (x, tau, globals), functions, typeString tau) 
end 
else 
let val tau' = find (x, globals) 
val tau = typeof (e, globals, functions, emptyEnv) 
in if eqType (tau, tau') then 
(globals, functions, typeString tau) 
else 
(raise TypeError with message about redefinition 342a) 
end 
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APPLY 332d 
badParameter 
$392b 
BEGIN 332d 
bind 305d 
BOOLTY 331f 
type def 333a 
emptyEnv 305a 
type env 304 
EQ 332e 
eqlype 332a 
eqTypes 332a 
find 305b 
functions 338a 
FUNTY 331f 
type funty 331f 
isbound 305c 
PRINT 332e 
PRINTLN 332e 
type ty 331f 
ty 338b 
TypeError $213c 
typeof 338a 
typeString S398e 
UNITTY 331f 
VAL 333a 
WHILEX 332d 


342a. (raise TypeError with message about redefinition 342a)= (341c) 
raise TypeError ("Global variable " A x A" of type " A typeString tau' A 
"may not be redefined with type " A typeString tau) 


A top-level expression must have a type, and it leaves the environments un- 


changed. 
(eT Fe: 
egal pe oe. (EXP) 
(exp(e), Pe, Py) > (Ve, 19) 
Type systems for 342b. (cases for typing definitions in Typed Impcore 341c) += (341b) <1341c 342c> 
Impcore and Scheme | EXP e => 


let val tau = typeof (e, globals, functions, emptyEnv) 
in (globals, functions, typeString tau) 
end 
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Like a variable definition, a function definition has two rules, depending on 
whether the function is already defined. 


T1,+++5Tn are types 
Tp=TM1 X00 X™mOT 
f ¢ domly 
Te, Te{f tt}, {21 71,.-.,2n mrp re:r 
(DEFINE(f, ((@1 : T1,---,2n!Tm),€:7)), Ve, Ue) 4 Ve, To{f  T¢}) 


(DEFINE) 
T1,+++,Tn are types 
lg(f) =m X +++ X ™mOT 
Ree Pe eg Se a i Ba Eh eee 
(DEFINE(f, ((@1 : T1,---,2n! Tm), €:7)), Ve, Ue) + Ve, Ty) 
(REDEFINE) 


The common parts of these rules are implemented first: build the function type, 
get the type of the body (7), and confirm that 7 is equal to the returns type in the 
syntax. Only then does the code check f € dom I’y and finish accordingly. 
342c. (cases for typing definitions in Typed Impcore 341c) += (341b) <342b 
| DEFINE (f, f{returns, formals, body?) => 
let val (fnames, ftys) = ListPair.unzip formals 


val def's_type = FUNTY (ftys, returns) 

val functions' = bind (f, def's_type, functions) 

val formals = mkEnv (fnames, ftys) 

val tau = typeof (body, globals, functions', formals) 


in if eqType (tau, returns) then 
if not (isbound (f, functions)) then 
(globals, functions', funtyString def's_type) 
else 
let val env's_type = find (f, functions) 
in if eqFunty (env's_type, def's_type) then 
(globals, functions, funtyString def's_type) 
else 
raise TypeError 
("Function "A f A " of type " A funtyString env's_type 
A" may not be redefined with type " A 
funtyString def's_type) 
end 
else 
raise TypeError ("Body of function has type " A typeString tau “A 
", which does not match declared result type " A 
"of " A typeString returns) 
end 


6.3 EXTENDING TYPED IMPCORE WITH ARRAYS 


Types are associated with data, and a designer who adds a new data structure must 
often add a new type. The process is shown here by adding arrays to Typed Imp- 
core. As shown below, arrays require new types, new concrete syntax, new abstract 
syntax, new evaluation code, and new typing rules. 


6.3.1 Types for arrays 


The array type is a different kind of thing from the integer, Boolean, and UNIT types. 
Properly speaking, “array” is not a “type” at all: it is a type constructor, i.e., a thing 
you use to build types. To name just a few possibilities, you can build arrays of in- 
tegers, arrays of Booleans, and arrays of arrays of integers. In general, given any 
type T, you can build the type “array of 7.” In our abstract syntax, the array type 
constructor is represented by ARRAY, and in the ML code, by ARRAYTY (chunk 331f). 
In the concrete syntax, it is represented by (array type) (page 330). So for exam- 
ple, the type of arrays of Booleans is (array boo1), and the type of arrays of arrays 
of integers is (array (array int)). 

“Type constructor” is such a useful idea that even INT, UNIT, and BOOL are often 
treated as type constructors, even though they take no arguments and so can be 
used to build only one type apiece. Such nullary type constructors are usually called 
base types, because the set of all types is defined by induction and the nullary type 
constructors are the base cases. 

Whenever you add a new type to a language, whether it is a base type or a more 
interesting type constructor, you also add operations for values of that type. Let’s 
look at operations for arrays. 


6.3.2 New syntax for arrays 


Like Typed Impcore’s equality and printing operations, each of its array operations 
gets its own syntactic form. 


To evaluate an expression of the form (make-array e€1 €2), we evaluate e; to 
get an integer size n and e2 to get a value v. We then allocate and return a 
new array containing n elements, each initialized to v; if n is negative, the 
evaluation results in a checked run-time error. A make-array expression is 
analogous to a creator (Section 2.5.2) for the array type. 


To evaluate an expression of the form (array-at €1 €2), we evaluate e, to get 
an array a and eg to get an integer index 7. We then return the ith element 
of a, where the first element is element number 0; if 7 is out of bounds, the 
evaluation results in a checked run-time error. An array-at expression is 
analogous to an observer for the array type. 


To evaluate an expression of the form (array-put €1 €2 €3), we evaluate e1 
to get an array a, €2 to get an integer index 7, and e3 to get a value v. We then 
modify a by storing v as its ith element; if 7 is out of bounds, the evaluation 
results in a checked run-time error. An array—put expression is analogous 
to a mutator for the array type. 


To evaluate an expression of the form (array-size e), we evaluate e to get 
an array a. We then return the number of elements in a. An array-size 
expression is analogous to an observer for the array type. 
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bind 305d 
DEFINE 333a 
emptyEnv 305a 
eqFunty 332b 
eqType 332a 
EXP 333a 
find 305b 
functions  341b 
FUNTY ait 
funtyString S398f 
globals 341b 
isbound 305c 
mkEnv 305e 
tau 341c 
tau' 341c 
TypeError $213c 
typeof 338a 


typeString S398e 


These operations can be illustrated with an array of Booleans. 


344a. (transcript 330) += <1331c 344b> 
-> (val truth-vector (make-array 3 (= 0 1))) 
[0 0 0] : (array bool) 
-> (array-put truth-vector 1 (= 0 @)) 
1: bool 
-> truth-vector 
[0 1 0] : (array bool) 
Type systems for 


As another example, array operators work on arrays that contain other arrays. 
Impcore and Scheme PS SE a y 


Such an array can represent a matrix: 


344 344b. (transcript 330) += 1344a 344c> 
-> (define (array (array int)) matrix-using-a-and-i 
; return square matrix of side length; a and i are for local use only 
({Llength : int] [a : (array (array int))] [i : int]) 
(begin 
(set a (make-array length (make-array 0 0))) 
(set i 0) 
(while (< i length) 
(begin 
(array-put a i (make-array length 0)) 
(set i (+ i 1)))) 
a)) 
-> (define (array (array int)) matrix ([length : int]) 
(matrix-using-a-and-i length (make-array 0 (make-array 0 0)) 0)) 


Function matrix fills a matrix with zeros; the matrix is updated using syntactic 
forms array-put and array-at. 


344c. (transcript 330) += <1344b 
-> (val a (matrix 3)) 
[LO 9 0] [0 0 0] [0 0 Oj] : (array (array int)) 
-> (val i 0) 
-> (val j 0) 
-> (while (< i 3) (begin 
(set j 0) 
(while (< j 3) (begin 
(array-put (array-at ai) j (+ i j)) 
(set j (+ j 1)))) 
(set i (+ i 1)))) 
>a 
[[O 1 2] [1 2 3] [2 3 4]] : (array (array int)) 
-> (val a.1 (array-at a 1)) 
[1 2 3] : Carray int) 
-> (val a.1.1 (array-at a.1 1)) 
2: int 
The array-at form operates on arrays of any type. As shown, it can index into an 
array of type (array int) and return a result of type int. It can also index into an 
array of type (array (array int)) and return a result of type (array int). Such 
behavior is polymorphic. Typed Impcore is monomorphic, which means that a func- 
tion can be used for arguments and results of one and only one type. So like = and 
println, array-at can't be implemented as a primitive function; it must be a syn- 
tactic form. In fact, every array operation is a syntactic form, defined as follows: 


344d. (array extensions to Typed Impcore’s abstract syntax 344d) = (332d) 
| AMAKE of exp * exp 
| AAT of exp * exp 
| APUT of exp * exp * exp 
| ASIZE of exp 


This example illustrates a general principle: in a monomorphic language, polymor- 
phic primitives require special-purpose abstract syntax. This principle also applies 
to C and C++, for example, which denote array operations with syntax involving 
square brackets. 

Each array operation is governed by rules that say how it is typechecked and 
evaluated. Type checking is presented in the next section; evaluation is presented 
here. Because the evaluation rules are not particularly interesting, they are omitted 
from this book; only the code is shown. 

Array operations expect arrays and integers, which are obtained from Typed 
Impcore values by projection (Section 5.2). The projections are implemented by 
functions toArray and toInt. If a program type checks, its projections should al- 
ways succeed; if a projection fails, there is a bug in the type checker. 


345a. (definitions of functions toArray and toInt for Typed Impcore 345a)= (S391b) 
toArray : value -> value array 
fun toArray (ARRAY a) = a toInt + value -> int 
| toArray _ = raise BugInTypeChecking "non-array value" 
fun toInt (NUM n) =n 
| toInt _ = raise BugInTypeChecking "non-integer value" 


Given toArray and toInt, the array operations are implemented using the 
Array module from ML’s Standard Basis Library. The library includes run-time 
checks for bad subscripts or array sizes; these checks are needed because Typed 
Impcore’s type system is not powerful enough to preclude such errors. 


345b. (more alternatives for ev for Typed Impcore 345b)= (S397b) 
| ev (AAT (a, i)) = ev : exp -> value 
Array.sub (toArray (ev a), toInt (ev i)) 

| ev (APUT (e1, e2, e3)) = 
let val (a, i, v) = (ev el, ev e2, ev e3) 
in Array.update (toArray a, toInt i, v); 


v 
end 
| ev (AMAKE (len, init)) = 
ARRAY (Array.array (toInt (ev len), ev init)) 
| ev (ASIZE a) = 
NUM (Array.length (toArray (ev a))) 


6.3.3 Rules for type constructors: Formation, introduction, and elimination 


In a monomorphic language, a new type constructor needs new syntax, and new 
syntactic forms need new typing rules. Like the operations described in Sec- 
tion 2.5.2, syntax should include forms that create and observe, as well as forms 
that produce or mutate, or both. Rules have similar requirements. 

Rules should say how to use the new type constructor to make new types. Such 
rules are called formation rules. Rules should also say what syntactic forms create 
new values that are described by the new type constructor. Such rules are called 
introduction rules; an introduction rule describes a syntactic form that is analo- 
gous to a creator function as described in Section 2.5.2. Finally, rules should say 
what syntactic forms use the values that are described by the new type constructor. 
Such rules are called elimination rules; an elimination rule describes a syntactic 
form that may be analogous to a mutator or observer function as described in Sec- 
tion 2.5.2. 
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ARRAY 332c 
BugInTypeChecking 

$213c 
ev S397b 
type exp 332d 
NUM 332c 
type value 332c 


A rule can be recognized as a formation, introduction, or elimination rule by 
first drawing a box around the type of interest, then seeing if the rule matches any 
of these templates: 


- A formation rule answers the question, “what types can I make?” Below the 
line, it has the judgment “ is a type,’ where is a type of interest: 


(FORMATION TEMPLATE) 


Type systems for is a type 
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+ An introduction rule answers the question, “how do I make a value of the 
346 interesting type?” Below the line, it has a typing judgment that ascribes the 
type of interest to an expression whose form is somehow related to the type. 
To write that expression, I use a ? mark: 


(INTRODUCTION TEMPLATE) 


TH?: 


+ An elimination rule answers the question, “what can I do with a value of the 
interesting type?” Above the line, it has a typing judgment that ascribes the 
type of interest to an expression whose form is unknown. Such an expression 
will be written as e, €1, e’, or something similar: 


Te: 


(ELIMINATION TEMPLATE) 


These templates work perfectly with the formation, introduction, and elimina- 
tion rules for arrays. To start, an array type is formed by supplying the type of its 
elements. In Typed Impcore, the length of an array is not part of its type.” 


T isa type 
ARRAY(T) is a type 


(ARRAYFORMATION) 


An array is made using make-array, which is described by an introduction rule. 


Te, 0,0, e1 : INT Te,U¢,P, e2:7 
Te, 0g, 0,  MAKE-ARRAY(€1, €2) : ARRAY(T) 


(MAKEARRAY) 


The MAKE-ARRAY form is definitely related to the array type, and this rule matches 
the introduction template. 

An array is used by indexing it, updating it, or taking its length. Each operation 
is described by an elimination rule. 


Te,0g,P, e1: apray(7) Te,0g,0,+ eg: INT 
Te, Uy, 0, - ARRAY-AT(€1, €2) : T 


(ARRAYAT) 


Te, P,P, e1 : ARRAY(T) Pe,0g,0,e2:1ntT Te, Tg,0,F e3: 7 
Te, Pg, 0, F ARRAY-PUT(€1, €2, €3) : T 


(ARRAYPUT) 


Te, 0 g,D, F e : ARRAY(T) 
Te, 0g, Pp - ARRAY-SIZE(€) : INT 


(ARRAYSIZE) 


Because the length of an array is not part of its type, Typed Impcore requires a run-time safety check 
for every array access. Such checks can be eliminated by a type system in which the length of an array 
is part of its type (Xi and Pfenning 1998), but these sorts of type systems are beyond the scope of this 
book. 


Understanding formation, introduction, and elimination 


Not all syntactically correct types and expressions are acceptable in programs; 
acceptability is determined by formation, introduction, and elimination rules. 
Formation rules tell us what types are acceptable; for example, in Typed Imp- 
core, int, bool, and (array int) are acceptable types, but (int bool), array, 
and (array array) are not. In C, unsigned and unsigned* are acceptable, but 
* and *unsigned are not. Type-formation rules are usually easy to write. 


Introduction and elimination rules tell us what terms (expressions) are accept- 
able. The words “introduction” and “elimination” come from formal logic; the 
ideas they represent have been adopted into programming languages via the 
principle of propositions as types. This principle says that a type constructor cor- 
responds to a logical connective, a type corresponds to a proposition, anda term 
of the given type corresponds to a proof of the proposition. For example, logical 
implication corresponds to the function arrow; if type 7 corresponds to propo- 
sition P, then the type 7 — 7 corresponds to the proposition “P implies P”; 
and the identity function of type 7 — 7 corresponds to a proof of “P implies P.” 


A term may inhabit a particular type “directly” or “indirectly.” Which is which 
depends on how the term relates to the type constructor used to make the 
type. For example, a term of type (array bool) might refer to the variable 
truth-vector, might evaluate a conditional that returns an array, or might ap- 
ply a function that returns an array. All these forms are indirect: variable ref- 
erence, conditionals, and function application can produce results of any type 
and are not specific to arrays. But if the term has the make-array form, it builds 
an array directly; a make-array term always produces an array. Similar direct 
and indirect options are available in proofs. 


In both type theory and logic, the direct forms are the introduction forms, and 
their acceptable usage is described by introduction rules. The indirect forms 
are typically elimination forms, described by elimination rules. For example, 
the conditional is an elimination form for Booleans, and function application is 
an elimination form for functions. In general, an introduction form puts new 
information into a proof or a term, whereas an elimination form extracts in- 
formation that was put there by an introduction form. For example, if I get a 
Boolean using array-at, I’m getting information that was in the array, so I’m 
using an elimination form for arrays, not an introduction form for Booleans. 


An introduction or elimination form is a syntactic form of expression, and it is 
associated with a type (or type constructor) that appears in its typing rule. An in- 
troduction form for a type constructor ju will have a typing rule that has a ys type 
in the conclusion; types in premises are often arbitrary types 7. An elimination 
form for the same ju will have a typing rule that has a u type in a premise; the 
type in the conclusion is often an arbitrary type 7, or sometimes a fixed type 
like bool. Identifying introduction and elimination forms is the topic of Exer- 
cise 2 (page 388). 


In a good design, information created by any introduction form can be extracted 
by an elimination form, and vice versa. A design that has all the forms and rules 
it needs resembles as design that has all the algebraic laws it needs, as discussed 
in Section 2.5.2 (page 111). Introduction forms relate to algebraic laws’ creators 
and producers, and elimination forms relate to observers. 
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In each of these rules, an expression of array type (€, or e) has an arbitrary syntac- 
tic form, which need not be related to arrays. These rules match the elimination 
template. 

These rules can be turned into code for the type checker, which you can fill in 
(Exercise 18): 


348. (function ty, checks type of nee) given '¢, 4,1’, [prototype] 348)= 


| ty (AAT (a, i)) = raise LeftAsExercise "AAT" 

| ty (APUT (a, i, e)) = raise LeftAsExercise "APUT" 
| ty (AMAKE (len, init)) = raise LeftAsExercise "AMAKE" 
| ty (ASIZE a) = raise LeftAsExercise "ASIZE" 


6.4 COMMON TYPE CONSTRUCTORS 


Arrays are just one type of data. Others include functions, products, sums, and mu- 
table references. All these types have proven their worth in many languages, and 
they all have standard typing rules, which are described in this section. The rules 
use a single type environment I’, which replaces the triple '¢, 'y, I, used in Typed 
Impcore. 


Functions Iffunctionsare first-class values, they should have first-class types. The 
function type constructor, which takes two arguments, is written using an infix —. 
Functions are introduced by \-abstraction and eliminated by function application. 
The \-abstraction I show here makes the types of the formal parameters explicit, 
like a function definition in Typed Impcore. And for simplicity, it takes just one 


parameter. 
T, and 72 are types 


- (ARROWFORMATION) 
T| — T2 1s atype 
a Aceae (ARROWINTRO) 
[TF LAMBDA(az :7,e): 7 > 7! 
Tre:tTO7' Th eg:T 
(ARROWELIM) 


TF appiy(ej, €2) : 7’ 


Products A product, often called a pair or tuple, groups together values of different 
types. It corresponds to ML’s “tuple” type, to C’s “struct,” to Pascal's “record,” and 
to the “Cartesian product” you may remember from math class. It is written us- 
ing an infix x. (To motivate the word “product,” think about counting inhabitants: 
if two values inhabit type bool and five values inhabit type lettergrade, how many 
values inhabit product type bool x lettergrade?) 

In addition to a formation rule, product types are supported by one introduction 


form, PAIR, and two elimination forms, FST and SND. 


T, and To are types 


- (PAIRFORMATION) 
T X Tg 1S atype 
Tre,:T Tb eg: 
pee cess (PAIRINTRO) 
TF patr(e1, €2) : 7 X Te 
Tre: xT 
jecereeeaea ae) (FST) 
[TF Fst(e): 7% 
Tre: xT 
: 2 (SND) 


TF snp(e) : 72 
Like array operations, the pair operations are polymorphic, i.e., they can work with 
pairs of any types. And the pair operations are familiar: they appear in Chapter 2 


under the names cons, car, and cdr. As noted in that chapter, their dynamic se- 
mantics is given by these algebraic laws: 


FST(PAIR(U1, U2)) = U1 
SND(PAIR(U1, V2)) = V2 


Pair operations can be written using other notations. Often PAIR(e1, €2) is writ- 
ten in concrete syntax as (€,, €2). Syntactic forms FST and SND may be written to 
look like functions fst and snd. In ML, these forms are written #1 and #2; in math- 
ematical notation, they are sometimes written 7, and 72. Or they may be written 
using postfix notation; for example, FsT(e) might be written as e.1. 

Using FST and SND to get the elements of a pair can be awkward. In ML code, 
there is a better idiom: pattern matching, which is combines elimination and bind- 
ing. The ML pattern match let val (a, y) =e’ ine end can be given a type as fol- 
lows: 

The’: X 72 
T{att1,yH to}Fe:7 


: LETPAIR 
[Fb let val (x, y) =e’ ineend: 7 ( ) 


The pair rules can be generalized to give types to tuples with any number of 
elements—even zero! The type of tuples with zero elements can serve as a UNIT 
type, since it is inhabited by only one value: the empty tuple. The tuple rules can 
be further generalized to give a name to each element of a tuple, so elements can be 
referred to by name instead of by position, something like a C struct (Exercise 5). 


Sums Wherea product provides an ordered collection of values of different types, 
a sum provides a choice among values of different types. And where products are 
supported in similar, obvious ways in almost every language, sums are supported 
in more diverse ways, some of which are hard to recognize. Easily recognizable 
examples include C’s “union” types and Pascal’s “variant records.” ML’s datatype is 
also a form of sum type. 

In type theory, a sum type is written T; + 72. A value of type 71 + 72 is either 
a value of type 7, or a value of type 72, tagged or labeled in a way that lets you 
tell which is which. (To motivate the word “sum,” count the inhabitants of type 
bool + lettergrade. If you're not sure about counting inhabitants, do Exercise 3.) 
In addition to a formation rule, sum types are supported by two introduction forms: 


T and To are types 
d 


: (SUMFORMATION) 
T1 + T2 isatype 
Te: i 
e€:T1 T2218 a DPE (LEFT) 
[TF LeFt,,(e) : 71 +72 
TFe:t% T, is a type” (RIGHT) 
TF RIGHT,, (e) : 7 +72 


Sum types are supported by a single elimination form: case, which in some lan- 
guages is called switch. Let the let pattern match above, a case expression has 
too many parts to be understood when written in abstract-syntax notation; the rule 
uses ML-like concrete syntax. 


Tre:m+7 
T{ap mph eit 
T{ag > Ta} eg: 7 
TF case e of LEFT(11) => e1 | RIGHT(%2) > €2: T 


(SUMELIMCASE) 
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Sums and case expressions behave as described by these rules of operational 
semantics, which use (unsubscripted) value forms LEFT(v) and RIGHT(v): 


(LEFT) (RIGHT) 
(e,p,0) 4 (v, 0") (e,p,0) 4 (v, 0") 


(LEFT, (e), p, 0) 4) (LEFT(v), 0’) (RIGHT, (e), p,o) | (RIGHT(v), 0”) 


(Gi, P; a) 1 (LEFT(v1), a’) 
Type systems for 0, ¢ domo! 
Impcore and juScheme (ey, p{z1 4 Qi}, 0'{0, 6 uh) Ue (v, 0”) 
(case e of LEFT(x1) = e1 | RIGHT(%2) > €2, 1,0) |) (v, a”) 
(e, P; o) (RIGHT(v2), a") 
ly € domo’ 


(€2, p{t2 + bo}, 0' {bo va}) 4 (v, 0") 
(case e of LEFT(x1) > e1 | RIGHT(r2) > €2, 9,0) |) (v, 0”) 


»  (CASELEFT) 
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(CASERIGHT) 


If a language has first-class functions, the case expression can be replaced with 
a simpler form, either. The expression (either e f g), which is equivalent to the 
case expression case e of LEFT(z,) = f(a1) | RIGHT(22) = g(22), applies 
either f or g to the value “carried” inside e. 

Just like products, sums can be generalized so that each alternative has a name 
(Exercise 6). 


Mutable cells The types shown above are all immutable, meaning that once cre- 
ated, a value can't be changed. Since mutation is a useful programming tech- 
nique, essential for both procedural and object-oriented programming, type sys- 
tems should support mutability—for example, with a type for “mutable cell con- 
taining value of type 7” (Exercise 7). 


6.5 TYPE SOUNDNESS 


If a program is well typed, what does that imply? It depends on the type system. 
A static type system should guarantee some properties about programs—usually 
safety properties. In other words, if a program type checks at compile time, that 
should tell you something about the program’s behavior at run time. 

A serious type system is designed around a safety property and supported by 
a proof that “well-typed programs don't go wrong,” i.e., that well-typed programs 
satisfy the safety property. The type systems in this book can guarantee such prop- 
erties as “the program never attempts to take car of an integer” or “a function is 
always called with the correct number of arguments.” More advanced type sys- 
tems can guarantee such properties as “no array access is ever out of bounds,” 
“no pointer ever refers to memory that has been deallocated,” or “no private in- 
formation is ever stored in a public variable.” Whatever the property of interest, 
the proof that a type system guarantees it is a soundness result. 

A precise claim about soundness might refer to the intended meaning of each 
type. One common meaning is that a type 7 prescribes a set of values [7]. For ex- 


ample, 
[int] = {NUMBER(7) | 7 is an integer} 
[bool] = {BOOLV(#t), BOOLV(#f)} 
[sym] = {sYMBOL(s) | sis a string} 
[7 > 7’] = aset of functions taking values in [7] to values in [7]. 


Asimple soundness claim might say that an expression of type T evaluates to a value 
in the set [7]. The claim is subject to conditions: evaluation must terminate, and 


evaluation and type checking must be done in compatible environments. A prop- 
erly phrased claim might read like this: 


If for any rindomI’, x € dompA p(x) € [I'(x)], andif[ F e: 7, 
and if (p, e) J) v, then v € [7]. 


That is, if the environments make sense, and if expression e has type T, and if eval- 
uating e produces a value, then evaluation produces a value in [7]. (To simplify 
the statement of the claim, I’ve used the simplest possible operational semantics, 
which uses no store.) A claim like this could be proved by simultaneous induction 
on the structure of the proof of [ | e : 7 and the proof of (p,e) 4) v. 

An even stronger soundness claim might add that unless a primitive like / or car 
fails, or unless e loops forever, that the evaluation of e does indeed produce a value. 
Using a small-step semantics like the one described in Chapter 3, such a claim 
might say that when all the expressions in an abstract machine are well typed, the 
machine has either terminated with a value and an empty stack, or it can step toa 
new state in which all its expressions are still well typed. 

A type system with a strong soundness claim rules out most run-time errors. 
For example, in a sound, typed, Scheme-like language, then if evaluating e does 
not attempt to divide by zero or take car or cdr of the empty list, and if evaluating e 
doesn’t get into an infinite loop, then the evaluation of e completes successfully. 


6.6 POLYMORPHIC TYPE SYSTEMS AND TYPED SCHEME 


The full benefits of types aren’t provided by Typed Impcore, which is both too com- 
plicated and not powerful enough. Typed Impcore is too complicated because of 
its multiple type environments I’¢, I's, and I’,. It is not powerful enough because 
each operation that works with values of more than one type, like = or print1n, has 
to be built into its abstract syntax. A function defined by a user can operate only 
on values of a single type, which is to say it is monomorphic. For example, a user 
can’t define a reusable array-reversal function that could operate on both an array 
of Booleans and an array of integers. This limitation is shared by such languages 
as C and Pascal. 

Monomorphism handicaps programmers. Many primitive structures, includ- 
ing arrays, lists, tables, pointers, products, sums, and objects, inherently work 
with multiple types: they are polymorphic. But when user-defined functions are 
monomorphic, a computation like the length of a list has to be coded anew for 
each type of list element, as in Chapter 1. 

And monomorphic languages are hard to extend with new type constructors. 
A language designer can do it, provided they are willing to add new rules to a type 
system and to revisit its proof of type soundness. But a programmer can’t; unless 
there is some sort of template or macro system, no programmer can add a user- 
defined, polymorphic type constructor such as the env type constructor used for 
environments in Chapters 5 to 10. At best, a programmer can add a new base type, 
not a new type constructor. 

These problems are solved by polymorphic type systems. Such type systems en- 
able a programmer to write polymorphic functions and to add new type construc- 
tors. Our first polymorphic type system is part of a language called Typed micro- 
Scheme, or Typed jsScheme for short. Typed Scheme is patterned after wScheme: 
it uses the same values as wScheme and similar abstract syntax. 

Our study of Typed jsScheme begins with concrete syntax. It continues with 
kinds and quantified types; these are the two ideas at the core of the type system. 
Kinds are used to ensure that every type written in the source code is well formed 
and meaningful; kinds classify types in much the same way that types classify 
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terms. Quantified types express polymorphism; they make it possible to imple- 
ment polymorphic operations using ordinary functions instead of special-purpose 
abstract syntax. Building on these ideas, the rest of the chapter presents techni- 
cal details needed to make a polymorphic type system work: type equivalence and 
substitution. Type equivalence is a relation that shows when two types cannot be 
distinguished by any program, even if they don’t look identical. And substitution is 
the mechanism by which a polymorphic value is instantiated so it can be used. 


6.6.1 Concrete syntax of Typed sScheme 
Typed Scheme is much like jzScheme, except as follows: 


* Function definitions and lambda abstractions require type annotations for 
parameters. 


Function definitions require explicit result types. 


+ All letrec expressions require type annotations for bound names—and each 
name may be bound only to a lambda abstraction. 


Instead of wScheme’s single val form, Typed jsScheme provides two forms: 
val-rec, which is recursive and defines only functions, and val, which is 
non-recursive and can define any type of value. Only the val-rec form re- 
quires a type annotation. Typed jzScheme’s val and val-rec forms resemble 
the corresponding forms in Standard ML. 


The type system of Typed jsScheme is more powerful than that of Typed Impcore: 


* Typed wScheme adds quantified types, which are written with forall. Val- 
ues of quantified type are introduced by a new syntactic form of expression: 
type-lambda. They are eliminated by the new syntactic form @. 


Syntactically, Typed jsScheme does not distinguish a “type” from a “type con- 
structor”; both can be called “types,” and both are in the syntactic category 
type-exp. The category, which is called “type-level expression,” also includes 
ill-formed nonsense that is neither type nor type constructor, like (int int). 


* In Typed wScheme, only the type constructor for functions requires special- 
purpose syntax; a function is introduced by lambda and eliminated by func- 
tion application. Other type constructors, like pairs and arrays, require no 
new syntax or new typing rules. They go into the initial basis, where their 
operations are implemented as ordinary (primitive) functions. 


The syntax of Typed jsScheme is shown in Figure 6.3 on the next page. 


6.6.2 A replacement for type-formation rules: Kinds 


Types in source code are written by programmers, and they can’t be trusted. 
“Types” like (int int) are ill formed and must be rejected. In Typed Impcore, 
types are determined to be well formed or ill formed by type-formation rules. And 
for a language with a fixed set of types and type constructors, that’s fine. But in 
Typed Scheme, we want to be able to add new type constructors without adding 
new rules. So Typed jzScheme uses just a few rules to encompass arbitrarily many 
type constructors. The rules rely on each type constructor having a kind. 

Kinds classify types (and type constructors) in much the same way that types 
classify terms. A kind shows how a type constructor may be used. For example, 


def = (val variable-name exp) 
(val-rec [variable-name : type-exp] exp) 86.6.2 


(define type-exp function-name (formals) exp) A replacement for 


exp type-formation 
(use file-name) rules: Kinds 
unit-test 
353 
unit-test i= (check-expect exp exp) 


(check-assert exp) 
(check-error exp) 
(check-type exp type-exp) 
(check-type-error def) 


exp = literal 

variable-name 

(set variable-name exp) 

(if exp exp exp) 

(while exp exp) 

(begin { exp}) 

(exp { exp} ) 

(let-keyword c{ [variable-name exp] } ) exp) 
(letrec [{ ([variable-name : type-exp] exp) } ] exp) 
(lambda (formals) exp) 

(type-lambda [type-formals] exp) 

[@ exp { type-exp }] 


let-keyword ::= let | let* 


formals = { [variable-name : type-exp] } 


type-formals ::= { : type-variable-name} 


type-exp = type-constructor-name 
| 'type-variable-name 
| (forall c{ ' type-variable-name}) type-exp) 
| ({ type-exp} -> type-exp) 
| (type-exp { type-exp}) 
literal 2S numeral | #t | tf | 'S-exp | (quote S-exp) 
S-exp = literal | symbol-name | ({S-exp}) 
numeral :!= token composed only of digits, possibly prefixed with a plus 
or minus sign 
*name ::= token that is not a bracket, a numeral, or one of the “re- 


served” words shown in typewriter font 


Figure 6.3: Concrete syntax of Typed uScheme 
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both int and array are type constructors of Typed Scheme, but they must be used 
differently. The int constructor is a kind of constructor that is a type all by itself; 
the array constructor is a kind of constructor that has to be applied to an element 
type in order to make another type. The first kind is written * and pronounced 
“type”; the second kind is written * => * and pronounced “type arrow type.” A kind 
is attributed to a type by a formal judgment: 7 :: & says that type constructor T 
has kind &. As a special case, the judgment “7 :: *” is equivalent to the judgment 
“7 is a type” used in Typed Impcore. 

Like types, kinds are defined inductively: there is one base kind, “type” («), and 
other kinds are made using arrows (=>). As concrete notation, we write 


Kus «| KL Xo X Kn > Ke 


Types that are inhabited by values, like int or (list bool), have kind *«. Types of 
other kinds, like list and array, are ultimately used to make types of kind *. 

Some common kinds, with example type constructors of those kinds, are as 
follows: 


* int, bool, unit 
k=> * list, array, option 
* xX * => * pair, sum, Standard ML’s -> 


More exotic kinds can be found in languages like Haskell, which includes not only 
“monads,” which are all types of kind *« => «, but also “monad transformers,” which 
are types of kind (* => *) = (* => x). 

Every syntactically expressible kind k is well formed: 


rE Ee (KINDFORMATIONTYPE) 
* is a kind 


K1,---,n are kinds «Kis a kind 


: : (KINDFORMATIONARROW) 
Ky X +++ X Ky => Kisakind 


How do we know which type constructors have which kinds? The kind of 
each type constructor is stored in a kind environment, written A. The exam- 
ple environment Ao below shows the kinds of the primitive type constructors of 
Typed wScheme. Each binding is written using the :: symbol, which is used instead 
of ++; it is pronounced “has kind.” 


Ao = {int :: *, bool :: *, unit :: *, pair ::* xX * => x, 
sum i: X * => -*, apray i: * => *, list: * => «} 


The kind environment determines how both int and array may be used. New 
type constructors can be added to Typed psScheme just by adding them to Ag (Ex- 
ercises 10 to 13). 

A kind environment is used to tell what types are well formed. No matter 
how many type constructors are defined, they are handled using just three type- 
formation rules: 


+ A type can be formed by writing a type constructor. In abstract syntax, a type 
constructor is written TYCON(,:), where pis the name of the constructor. In 
concrete syntax it is written just using its name, like int or list. A type 
constructor is well formed if and only if it is bound in A. 


+ A type can be formed by applying a type to other types. In abstract syntax, 
type application is written CONAPP(T, [71,..., Tn]), where 7 and 71,..., Tn 


are type-level expressions. In concrete syntax, application of a type con- 
structor is written using the same concrete syntax as application of a func- 
tion. For example, (list int) is the type “list of integer.” A constructor ap- 
plication is well formed if its arguments have the kinds it expects, as formal- 
ized in the KINDAPP rule below. 


« A type can be a function type. In abstract syntax, itis T; X +--+: X T, — T, 
where 71,..., Tn are the argument types and 7 is the result type. In concrete 
syntax, a function type is (7, --- T, -> 7).° A function type is well formed 
if and only if types 7, to 7, and 7 all have kind *. 


These rules are formalized using the kinding judgment Al 7 :: k. This judgment 
says that in kind environment A, type-level expression 7 has kind «. Kinds classify 
types in much the same way that types classify expressions. 


pe € dom A 
AF Tycon(p) :: A(t) 


(KINDINTROCON) 


AF Ti ky Xs X kn SK AFR 2k, 1L<i<n 
AF CONAPP(T, [71,---5T7n]) 2 & 
AFR, 1<i<n AFT: * 
AFT X ++ X TOT 


(KINDAPP) 


(KINDFUNCTION) 


No matter how many type constructors we may add to Typed psScheme, these kind- 
ing rules tell us everything we will ever need to know about the formation of 
types. Compare this situation with the situation in Typed Impcore. In Typed Imp- 
core, we need the BASETYPES rule for int and bool. To add arrays we need the 
ARRAYFORMATION rule. To add lists we would need a list-formation rule (Exer- 
cise 4, page 389). Andsoon. Unlike Typed Impcore’s type system, Typed juScheme’s 
type system can easily be extended with new type constructors (Exercises 10 to 13). 
Similar ideas are used in languages in which programmers can define new type con- 
structors, including jsML and Molecule (Chapters 8 and 9). 


Implementing kinds 


A kind is represented using the datatype kind. 


355a. (kinds for typed languages 355a)= (S405a) 355b> 
datatype kind = TYPE (* kind of all types *) 
| ARROW of kind list * kind (* kind of many constructors *) 
Kinds are equal if and only if they are identical. 
355b. (kinds for typed languages 355a) += (S405a) <1355a 
eqKind : kind * kind -> bool 


fun eqKind (TYPE, TYPE) = true eqKinds : kind list * kind list -> bool 


| eqKind (ARROW (args, result), ARROW (args', result')) = 
eqKinds (args, args') andalso eqKind (result, result') 
| eqKind (_, _) = false 
and eqKinds (ks, ks') = ListPair.allEq eqKind (ks, ks') 


3The arrow that signifies a function occurs in the middle of the parentheses, between types. In other 
words, the function arrow -> is an infix operator. This infix syntax violates Lisp’s prefix convention, in 
which keywords, type constructors, and operators always come first, immediately after an open paren- 
thesis. Prefix syntax might look like “(function (71 ... Tn) 7).” But when functions take or return 
other functions, prefix syntax is too hard to read. 
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The kinds of the primitive type constructors, which populate the initial kind 
environment Ao, are represented as follows. 
356. (primitive type constructors for Typed t1Scheme :: 356) = (382c) 
("int", TYPE) :: 
("bool", TYPE) :: 
C"sym", TYPE) :: 
C"unit", TYPE) :: 
("list", ARROW ([TYPE], TYPE)) :: 
The kind system and the type-formation rules shown above replace the type- 
formation rules of Typed Impcore. To get polymorphism, however, we need some- 
thing more: quantified types. 


6.6.3 The heart of polymorphism: Quantified types 


Polymorphic functions aplenty can be found in Chapter 2; one of the simplest is 
length. As defined in (untyped) uScheme, length can be applied to any list of 
values, no matter what the types of its elements: 


(define length (xs) 
(if (null? xs) 0 (+ 1 (length (cdr xs))))) 


Suppose length could be defined in Typed Impcore; what would its type be? Ina 
monomorphic language like Typed Impcore or C, a function can have at most one 
type, so the definition would have to designate an element type. To use length with 
different types of lists would require different versions: 


(define int lengthI ([xs : (list int)]) 

(if (null? xs) 0 (+ 1 (lengthI (cdr xs))))) 
(define int lengthB ([xs : (list bool)]) 

(if (null? xs) 0 (+ 1 (lengthB (cdr xs))))) 
(define int lengthS ([xs : (list sym)]) 

(if (null? xs) 0 (+ 1 (lengthS (cdr xs))))) 


Such duplication wastes effort; except for the types, the functions are identical. but 
Typed Impcore’s type system cannot express the idea that length works with any 
list, independent of the element type. To express the idea that length could work 
with any element type, we need type variables and quantified types. 

A type variable stands for an unknown type; a quantified type grants permis- 
sion to substitute any type for a type variable. In this book, type variables are written 
using the Greek letters a, 0, and 7; quantified types are written using V. For ex- 
ample, the type of a polymorphic length function is Va . a list — int. Greek 
letters and math symbols can be awkward in code, so in Typed psScheme this type 
is written (forall ['a] ((list 'a) -> int)). 

A forall type is not a function type; the length function can’t be used on a list 
of Booleans, for example, until it is instantiated. The instantiation (@ length bool) 
strips “Va.” from the front of length’s type, and in what remains, substitutes bool 
for w. The type of the resulting instanceis bool list — bool, orin Typed psScheme, 
((list bool) -> int). This instance can be applied to a list of Booleans. 

Like lambda, V is a binding construct, and the variable a is sometimes called a 
type parameter. Like the name of a formal parameter, the name of a type parameter 
doesn’t matter; for example, the type of the length function could also be written 
VG .61list — int, and its meaning would be unchanged. That’s because the 
meaning of a quantified type is determined by how it behaves when we strip the 
quantifier and substitute for the bound type variable. 


In abstract syntax, type variables and quantified types are written using TYVAR 
and FORALL. And like TYCON and CONAPP, TYVAR and FORALL are governed by 
kinding rules. (The kind system replaces the type-formation rules used in Typed 
Impcore; remember the slogan “just as types classify terms, kinds classify types.”) 

The kind of a type variable, like the kind of a type constructor, is looked up in 
the environment A. 


a€domA 
AF TYVAR(q) :: A(a@) 


(KINDINTROVAR) 


The kind of a quantified type is always *, and the FORALL quantifier may be used 
only over types of kind +. Within the body of the FORALL, the quantified variables 
stand for types. So above the line, they are introduced into the kind environment 
with kind x. 

Afay i *...,An kb} Ts 
AF FORALL((Q1,...,Qn),T7) 2 * 


(KINDALL) 


In some polymorphic type systems, including the functional language Haskell, type 
variables may have other kinds. 

In Typed juScheme, every type is written using a type-level expression (nonter- 
minal type-exp in Figure 6.3, page 353). In the interpreter, a type-level expression 
is represented by a value of the ML type tyex; its forms include not only TYVAR and 
FORALL but also TYCON, CONAPP, and a function-type form. 
357a. (types for Typed uScheme 357a) = ($405a) 38la> 

datatype tyex = TYCON of name (* type constructor *) 
| CONAPP of tyex * tyex list (* type-level application *) 
| FUNTY of tyex list * tyex (* function type *) 
| FORALL of name list * tyex (* quantified type *) 
| TYVAR of name (* type variable *) 


Even though not every tyex represents a well-formed type, it’s easier to call them 
all “types”—except when we have to be careful. 

Examples of well-formed types, written using concrete syntax, include the 
types of the following polymorphic functions and values related to lists: 


357b. (transcript 357b) = 358a > 
-> length 
<function> : (forall ['a] ((list 'a) -> int)) 
-> cons 
<function> : (forall ['a] ('a (list 'a) -> (list 'a))) 
-> car 
<function> : (forall ['a] ((list 'a) -> 'a)) 
-> cdr 
<function> : (forall ['a] ((list 'a) -> (list 'a))) 
> 'C 


© : (forall ['a] (list 'a)) 


Polymorphism is not restricted to functions: even though it is not a function, the 
empty list has a quantified type. 

The parenthesized-prefix syntax above is easy to parse and easy to understand, 
but not so easy to read. So I also use an algebraic notation in which type construc- 
tors are ju, type variables are a, and types are T. I follow the ML postfix convention 
for application of type constructors, and I use special notation for the function con- 
structor: 


eo Oe) Gigs oon Fa) T| NOt tek sia ait TX +++ XT OT. 
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Using this special notation, the types of length, cons, car, cdr, and '() are written 
as follows: 


length : Va.alist > int 
cons :Va.axXalist > alist 


car :Va@.alist >a 
cdr :Va@.alist > alist 
me) :Va.q@list 


A function (or other value) with a quantified type can’t be used until it is instan- 
tiated. Instantiation determines what type each bound type variable stands for. 
A polymorphic expression is instantiated by a syntactic form, written with @ sym- 
bol, which gives the expression to be instantiated plus a type to be substituted for 
each bound type variable. Instantiation produces an instance. Both the instantia- 
tion and the instance may be pronounced with the word “at,” as in “length at inte- 
ger,” which would be appropriate in these examples:* 


358a. (transcript 357b) += <1357b 358b> 

-> (val length-at-int [@ length int]) 

length-at-int : ((list int) -> int) 

-> (val cons-at-bool [@ cons bool]) 

cons-at-bool : (bool (list bool) -> (list bool)) 

-> pair 

<function> : (forall ['a 'b] ('a 'b -> (pair 'a 'b))) 

-> (val car-at-pair [@ car (pair sym int)]) 

car-at-pair : ((list (pair sym int)) -> (pair sym int)) 

-> (val cdr-at-sym [@ cdr sym]) 

cdr-at-sym : ((list sym) -> (list sym)) 

-> (val empty-at-int [@ '() int]) 

Q : (list int) 
In each case, the type of the instance is obtained by substituting each type parame- 
ter for the corresponding type variable in the forall. Each instance is monomor- 
phic, and if it has an arrow type, it can be applied to values. 
358b. (transcript 357b) += <1358a 358c> 

-> (length-at-int '(1 4 9 16 25)) 

5 $ ant 

-> (cons-at-bool #t '(#f #f)) 

(#t #f #f) : (list bool) 

-> (car-at-pair ([@ cons (pair sym int)] 

({@ pair sym int] 'Office 231) 
[@ '() (pair sym int)])) 

(Office . 231) : (pair sym int) 

-> (cdr-at-sym '(a bc d)) 

(b c d) : (list sym) 

Getting the instances you want takes thought and practice. A common mistake 
is to instantiate by substituting the type you want the instance to have. If you wanta 
function of type ((list bool) -> int), instantiate length at bool. Ifinstead you in- 
stantiate length at the desired type ((list bool) -> int), the instance won't have 
the type you hoped for: 
358c. (transcript 357b) += <1358b 359a> 

-> (val useless-length [@ length ((list bool) -> int)]) 
useless-length : ((list ((list bool) -> int)) -> int) 


‘Instantiation is also called type application. It is deeply related to function application. Instantiation 
is defined by substituting for type variables bound by V. And in Alonzo Church’s fundamental theory of 
programming languages, the lambda calculus, function application is defined by substituting for term 
variables bound by A. 


A function like useless-length has a good type but can’t be used to take the 
length of a list of Booleans. 
359a. (transcript 357b) += <1358c 362> 

-> (useless-length '(#t #f #f)) 

type error: function useless-length of type ... 

-> [@ length bool] 

<function> : ((list bool) -> int) 

-> ([@ length bool] '(#t #f #f)) 

3.saint 
As the car-at-pair example and the final two length examples show, an instance 
doesn’t have to be named; instances can be used directly. 

The instantiation form @ lets you use a polymorphic value; it is the elimination 
form for quantified types. To create a polymorphic value you need an introduction 
form. In Typed wScheme, the introduction form is written using type-lambda; it is 
sometimes called type abstraction. As an example, I use type-lambda to define the 
polymorphic functions list1, list2, and list3. 
359b. (predefined Typed Scheme functions 359b) = 359c > 

(val list1 (type-lambda ['a] (lambda ([x : 'a]) 
([@ cons 'a] x [@ '() 'a])))) 
(val list2 (type-lambda ['a] (lambda ([x : 'a] [y : 'a]) 
([@ cons 'a] x ([@ listl 'a] y))))) 
(val list3 (type-lambda ['a] (lambda ([x : 'a] [y : 'a] [z: 'a]) 
([@ cons 'a] x ([@ list2 'a] y z))))) 

As another example, type-lambda is used to define some of the higher-order 

functions in Chapter 2. Their types are as follows: 


0 :Va, B,y.(B + 7) x (@ > B) > (a> 9) 
curry :Va,B,y.(ax Boy) > (a> (8B 7)) 
uncurry : Va, 8,y.(a— (6 > 7)) > (ax B> 7) 


Their implementations use only type-lambda, lambda, and function application: 


359c. (predefined Typed puScheme functions 359b) += <1359b 359d > 
(val o (type-lambda ['a 'b 'c] 
(lambda ([f : ('b -> 'c)] [g : ('a -> 'b)]) 
(lambda ([x : 'a]) (f (g x)))))) 


(val curry (type-lambda ['a 'b 'c] 
(lambda ([f : ('a 'b -> 'c)]) 
(lambda ([x : 'a]) (lambda ([y : 'b]) (f x y)))))) 


(val uncurry (type-lambda ['a 'b 'c] 
(lambda ([f : ('a -> ('b -> 'c))]) 
(lambda ([x : 'a] [y = 'b]) ((f x) y))))) 

Other higher-order functions are not only polymorphic but also recursive. 
Such functions are defined by nesting letrec (for recursion) inside type-lambda 
(for polymorphism). 
359d. (predefined Typed Scheme functions 359b) += <1359¢ 360a> 

(val length 
(type-lambda ['a] 
(letrec 
[C{[length-mono : ((list 'a) -> int)] 
(lambda ([xs : (list 'a)]) 
(if ({@ null? 'a] xs) 
0 
(+ 1 (length-mono ([@ cdr 'a] xs))))))] 
length-mono) )) 
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The inner function is called length-mono because it—like any value introduced with 
lambda—is monomorphic, operating only on lists of the given element type 'a: the 
recursive call to length-mono does not require an instantiation. 

Every polymorphic, recursive function is defined using the same pattern: val 
to type-lambda to letrec. Another example is an explicitly typed version of the 
reverse-append function: 
360a. (predefined Typed puScheme functions 359b) += <1359d 360b> 

(val revapp 
(type-lambda ['a] 
(letrec [([revapp-mono : ((list 'a) (list 'a) -> (list 'a))] 
(lambda ([xs : (list 'a)] [ys : (list 'a)]) 
(if ({@ null? 'a] xs) 
ys 
(revapp-mono ([@ cdr 'a] xs) 
([@ cons 'a] ([@ car 'a] xs) ys)))))] 
revapp-mono) ) ) 
As another example, filter is defined as follows: 
360b. (predefined Typed Scheme functions 359b) += <1360a 360c> 
(val filter 
(type-lambda ('a) 
(letrec 
[({filter-mono : (('a -> bool) (list 'a) -> (list 'a))] 
(lambda ([p? : ('a -> bool)] [xs : (list 'a)]) 
(if ([@ null? 'a] xs) 
[@ '() 'a] 
(if (p? ({@ car 'a] xs)) 
({@ cons 'a] ([@ car 'a] xs) 
(filter-mono p? ([@ cdr 'a] xs))) 
(filter-mono p? ([@ cdr 'a] xs))))))] 
filter-mono))) 
And likewise map: 
360c. (predefined Typed puScheme functions 359b) += <1360b 
(val map 
(type-lambda ('a 'b) 
(letrec 
[([map-mono : (('a -> 'b) (list 'a) -> (list 'b))] 
(lambda ([f : ('a -> 'b)] [xs : (list 'a)]) 
(if ([@ null? 'a] xs) 
[@ '() 'b] 
([@ cons 'b] (f ([@ car 'a] xs)) 
(map-mono f ([@ cdr 'a] xs))))))] 
map-mono))) 


As shown by these examples, explicit types and polymorphism impose a no- 
tational burden. At the cost of a little expressive power, that burden can be lifted 
by type inference, as in nano-ML (Chapter 7). Or the burden can be lightened by 
instantiating an entire module at once, as in Molecule (Chapter 9). 

To summarize this section, the essential new idea in a polymorphic type system 
is the quantified type. It comes with its own special-purpose syntax: forall to form 
a quantified type, type-lambda to introduce a quantified type, and @ to eliminate a 
quantified type. The rest of this chapter shows how quantified types are combined 
with jsScheme to produce Typed wScheme. 


6.6.4 Abstract syntax, values, and evaluation of Typed zScheme 


Like the concrete syntax, the abstract syntax of Typed zScheme resembles the ab- 
stract syntax of wScheme. Typed jsScheme adds two new expressions, TYLAMBDA 
and TYAPPLY, which introduce and eliminate quantified types. And it requires that 
names bound by letrec or lambda (internal recursive functions and the parame- 
ters of every function) be annotated with explicit types. 


$6.6.4 
Abstract syntax, 
values, and 


361a. (definitions of exp and value for Typed puScheme 361a)= (S405b) 361b> evaluation of 
datatype exp = LITERAL of value 
ne on rae Typed pScheme 
SET of name * exp 361 
IFX of exp * exp * exp 


WHILEX of exp * exp 

BEGIN of exp list 

APPLY of exp * exp list 

LETX of let_flavor * (name * exp) list * exp 
LETRECX of ((name * tyex) * exp) list * exp 
LAMBDA of lambda_exp 

TYLAMBDA of name list * exp 

TYAPPLY of exp * tyex list 

and let_flavor = LET | LETSTAR 


The values of Typed jzScheme are the same as the values of juScheme; adding a type 
system doesn’t change the representation used at run time. 


361b. (definitions of exp and value for Typed Scheme 361a) += (S405b) <361la 
and value = NIL 
| BOOLV of bool 
| NUM of int 
| SYM of name 
| PAIR of value * value 
| 


CLOSURE of lambda_value * value ref env 
PRIMITIVE of primitive 


withtype primitive = value list -> value (* raises RuntimeError *) 
and lambda_exp = (name * tyex) list * exp 
and lambda_value = name list * exp 


The definitions of Typed Scheme are like those of Typed Impcore, plus the 
recursive binding form VALREC (see sidebar on the following page). 
361c. (definition of def for Typed t1Scheme 361c)= (S405b) 
datatype def = VAL of name * exp 
| VALREC of name * tyex * exp 
| EXP of exp 
| DEFINE of name * tyex * lambda_exp 


. type env 304 
6.6.5 Typing rules for Typed uScheme type name 303 


type tyex 357a 
The typing rules for Typed wScheme are very like the rules for Typed Impcore. 


The important differences are these: 
* There is only one type environment, I’. It maps values to types. 


* There is a kind environment, A, which keeps track of the kinds of type vari- 
ables and type constructors. 


* There are no special-purpose typing rules associated with individual type 
constructors. Type formation is handled by the general-purpose kinding 
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Language design: True definitions in a typed language with lambda 


Like Scheme, Typed uScheme has more definition forms that it really needs: 
given its lambda and letrec expressions, the only definition form it really needs 
is val (Exercise 21). But Typed Scheme is not meant to be as small as possible; 
it’s meant to convey understanding and to facilitate comparisons. So it includes 
define. 


In untyped uScheme, define is just syntactic sugar for a val binding to a lambda 
(page 120). Because a puScheme val makes its bound name visible on the right- 
hand side, such functions can even be recursive. jsScheme’s operational seman- 
tics initializes the name to an unspecified value, then overwrites the name with 
a closure. This semantics extends to all val bindings; for example, in untyped 
pScheme you can write (val n (+n1)), and on the right-hand side, the value 
of nis unspecified. But in Typed Scheme, we can’t afford to compute with un- 
specified values; if an expression like (+ n 1) typechecks, we have to know that 
n has an integer value. 


Typed wScheme works around this problem by changing the operational se- 
mantics of val back to the semantics used in Impcore: in Typed Scheme, as 
in Impcore, a val binding is not recursive, and the name being defined is not 
visible on the right-hand side. 
362. (transcript 357b) += <1359a 368a> 
-> (val n (+ n 1)) 
Name n not found 


For recursive bindings, Typed jsScheme introduces the new form val-rec, 
which has the same operational semantics as jsScheme’s val form. To en- 
sure that the right-hand side does not evaluate the name before it is initialized, 
Typed Scheme restricts the right-hand side to be a lambda form. And to make 
it possible to typecheck recursive calls, Typed «Scheme requires a type annota- 
tion that gives the type of the bound name. Using val-rec and lambda, define 
can easily be expressed as syntactic sugar. 


The distinction between val and val-rec can be found in other languages. Look 
for it! For example, in C, type definitions act like val, but in Modula-3, they act 
like val-rec. And in Haskell, every definition form acts like val-rec! (Haskell 
gets away with this because no definition form evaluates its right-hand side.) 


rules; introduction and elimination are handled by the general-purpose typ- 
ing rules for type abstraction, instantiation, lambda abstraction, and appli- 
cation. 


Two technical details should not be overlooked: 


* In a forall type, the names of quantified type variables are not supposed 
to matter. This detail affects any decision about whether two types are the 
same. 


* Type application using @ works by substituting a type for a type variable. And 
when forall types are nested, substitution is easy to get wrong. 


As I present the rules, I take it for granted that the names of quantified type vari- 
ables don’t matter and that substitution is implemented correctly. To enable you to 
implement the rules, I then present detailed implementations of type-equivalence 
testing and substitution (Sections 6.6.6 and 6.6.7). 


Typing rules for expressions 


The typing judgment for an expression is} A, e : 7 |, meaning that given kind 


environment A and type environment I’, expression e has type Tr. Each form of e 
has its own rule or rules, starting with literal expressions. 

The type of a literal depends only on its value; different forms of value have 
different rules. The rules force lists to be homogeneous, with one fine point: empty 
lists are polymorphic, but nonempty lists are monomorphic. 


A,TF LITERAL(NUM(n)) : int A,T LITERAL(BOOLV(n)) : bool 
(LITERALS1) 


(LITERALS2) 


A,T LITERAL(SYM(n)) : sym 
A, TF LITERAL(v) : T 


A,UF LITERAL(NIL) : Va. a@ list A,T LITERAL(PAIR(v, NIL)) : 7 List 
(LISTLITERALS1) 


A, TE uirerat(v):7 A,E- LITERAL(v’): 7 list 


LISTLITERALS2 
A,TF LITERAL(PAIR(v, v’)) : 7 list ( ) 


A use of a variable x is well typed if x is bound in the type environment I. 
The variable x may also be assigned to, provided the type of the right-hand side is 


also the type of x. 
xé€domT I[(#)=r 


A,T FF var(a) : 7 
A,TFe:7 «é€doml (a) =7 
A,TF set(a,e) : 7 
As in Typed Impcore, a while loop is well typed if the condition is Boolean and 
the body is well typed. The result has type unit. 


A,TF e; : bool A,TFe.:T 
A, WHILE(e;, eg) : unit 


(VAR) 


(SET) 


(WHILE) 


Also asin Typed Impcore, a conditional expression is well typed if the condition 
is Boolean and the two branches have the same type T. In that case, the type of the 
conditional expression is also T. 

A,TF e; : bool A, TF e.:7 A, TF e3 : 7 
A, TF 1F(e1, €2, €3) : T 


(IF) 


As in Typed Impcore, a sequence is well typed if its subexpressions are well 


typed. 
A,Tbe:7, 1<i<n 


A,TF BEGIN(e1,...,@€n) : Tn 
Also as in Typed Impcore, the empty BEGIN has type unit. 


(BEGIN) 


EMPTYBEGIN 
A,U- BEGIN() : unit ( ) 


A LET expression is well typed if all of the right-hand sides are well typed, and 
if in an environment extended with the types of the bound names, the body is well 
typed. The type of the LET expression is the type of the body. 

A,TFe:t%, 1<i<n A, Tf{ay 9 ],..-,2n > Trb rh e:T 

A, TF Let ((a1,€1,.-.,2n,€n),€) 2 T 


(LET) 


The rule applies equally well to the empty LET. 
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Recursive letrec bindings in a typed language 


The letrec form is intended for recursive functions. In a form like 


(letrec [([f1:71] €1) 
(L fo: 72] €2)] 
e), 


each bound name /f; is visible during the evaluation of each right-hand side e;. 
But at run time, f; and f2 don’t get their values until after e; and e2 have been 
evaluated. The operational semantics leaves their initial values unspecified: 


£1, € domo (and all distinct) 
p= ptfir fi, fo bo} 
oo = o{f; + unspecified, f2 ++ unspecified} 
(e1, 9’, 00) Y (v1,01) 
(e2, p',01) 1 (v2, 02) 
(e, p', a{ £1 > U1, £2 4 v2}) I (vu, 0") 
(LETREC((f1 : 71, €1, fo : T2,€2),€),p,0) 4 (v, 0’) 


(LETREC2) 


While e; and e2 are being evaluated, the contents of (; and fz are unspecified, 
and therefore untrustworthy. In particular, the contents of ¢; and (2 are in- 
dependent of the types 7; and 72. While e is being evaluated, by contrast, the 
contents of £; and f do respect types 7; and 72, and so f; and f2 can be eval- 
uated safely. To preserve type safety, then, Typed 4Scheme’s type system must 
prevent f; and f2 from being evaluated until after 0; and fz have been updated 
to hold values vj and v2. And in ppScheme, the way to keep something from be- 
ing evaluated is to protect it under a LAMBDA. (Ina lazy language like Haskell, a 
right-hand side is never evaluated until its value is needed, so Haskell’s letrec is 
not restricted in this way.) Typed zScheme uses the same tactic as the ML family 
of languages: it requires that the right-hand sides e; and e2 be LAMBDA forms. 
So letrec is useful only for defining recursive functions, including mutually re- 
cursive functions. 


A LETREC is well typed when the corresponding LET is well typed, except that 
each right-hand side e; can refer to any of the bound names «;. So the right-hand 
sides are typechecked in the extended environment {x +> 71,...,%n 0 Tn}. 
Types 71 to T,, which are written in the syntax, must all have kind «. 


AFR: *, l<i<n 
A, Tf{ai > 1,-.-,2n Ombre: tT, 1<ic<n 
A, TPfa4 74,..-,%n te Tbr e:T 
’ { 1 1; 9&n ne (LETREC) 
A, TF LETREC((21 : 71, €1,---,2n : Tn; Cn), €) 2 T 


Asin untyped jScheme, the parser ensures that every e; has the form of a LAMBDA. 
This requirement prevents any e; from evaluating an uninitialized x; (see sidebar 
above). 

A rule for LETSTAR would be annoying to write down directly—it would require 
a lot of bookkeeping for environments. Instead, I use syntactic sugar. A LETSTAR is 


well typed if the corresponding nest of LETs is well typed. 


A, TF LET ((x1, €1), LETSTAR( (2, €2,---;%n,€n),€)):T n>O 
A, TF LETSTAR((21, €1,---,2n;€n),€) 2 T 
(LETSTAR) 
A,TFe:f 
(EMPTYLETSTAR) 


A, LEeTstar((),e) : 7 
A function is well typed if its body is well typed, in an environment that gives 
the types of the arguments. These types must be well formed and have kind «. The 
type of the body is the result type of the function. 
AFayiu*, 1<i<n A, Tf{a1 > 1,..-,0n > Tbr e:r 
A, TF LAMBDA((a1 : 71,---,2n 2 Tn),€) 2 T1 X00 X Ta DT 


(LAMBDA) 


An application is well typed if the term being applied has an arrow type, and if 
the types and number of actual parameters match the types and number of formal 
parameters on the left of the arrow. The type of the application is the type to the 
right of the arrow (the result type). 

A,The:% X+++X mT A,Tre:t, 1<i<n 
A,TF AppLy(e,e1,...,€n) 27 


(APPLY) 


The most interesting rules, which have no counterpart in Typed Impcore, 
are for type abstraction and application, which introduce and eliminate polymor- 
phism. The elimination form is simpler. To use (“eliminate”) a polymorphic value, 
one chooses the types with which to instantiate the type variables. A type applica- 
tion is well typed if the instantiated term has a quantified type with the expected 
number of bound type variables, and if every actual type parameter (7) to 7,,) has 
kind *. The notation [a1 +> 71,...,@n +9 Tn] indicates the simultaneous, capture- 
avoiding substitution of 7; for a1, T2 for a2, and so on. 


A,TF e:Vay,...,Qn.T AFR: l<i<n 
A, TF TYAPPLy(e,71,.--, Tn): T[Q1 > T1,---, Qn 9 Trl 


(TYAPPLY) 


Simultaneous means “substitute for all the a,’s at once,” not one at a time. Simul- 
taneous substitution can differ from sequential substitution if some 7; contains 
an a. Capture-avoiding means that the substitution doesn’t inadvertently change 
the meaning of a type variable; the details are explored at length in Section 6.6.7 
(page 371). 

The TYAPPLY rule justifies my informal claim that the names of quantified type 
variables don’t matter. All you can do with a value of quantified type is substitute 
for its type variables, and once you substitute for them, they are gone. The names 
exist only to mark the correct locations for substitution—no more, and no less. 

The introduction form for a quantified type is type abstraction. To create (“in- 
troduce”) a polymorphic value, one abstracts over new type variables using Ty- 
LAMBDA. The type variables go into the kind environment A. In Typed Scheme, 
type variables always stand for types, so they have kind «. (In related, more am- 
bitious languages like Haskell or F.,,, a type variable may have any kind.) A type 
abstraction is well typed if its body is well typed—and the body may refer to the 
newly bound type variables. 


a, éftv(T), l<i<n  Afay:,...a,:*}, TF e:7 
A,TF TYLAMBDA(Q1,...,Qn,€) : VQ1,.--,Qn-T 


(TYLAMBDA) 


A type abstraction must also satisfy the side condition a; ¢ ftv(I). Why? The 
set ftv(I‘) contains the free type variables of I (page 372), and the side condition is 
needed to avoid changing the meaning of a; in e. This need is illustrated in Sec- 
tion 6.6.9 (page 377). 
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Typing rules for definitions 


Just as in the operational semantics, a definition can produce a new environment. 
The new environment is a type environment, not a value environment: it con- 
tains the types of the names introduced by the definition. As in Typed Impcore, 
the new environment is produced by typing the definition. The relevant judg- 


ment has the form | (d, A,T) — I’ |, which says that when definition d is typed 


in kind environment A and type environment I’, the new type environment is I’. 
In Typed jzScheme, a definition does not introduce any new types, so typing a def- 
inition leaves A unchanged. 

A VAL binding is not recursive, so the name being bound is not visible to the 
right-hand side. 

A,TRe:7 
(vAL(a,e), A,T) > {a 7} 

A VAL-REC binding, by contrast, is recursive, and it requires an explicit type T. 
Type 7 must be well formed and have kind «, and it must be the type of the right- 
hand side. 


(VAL) 


AFT: 
A, T{awHrhke:r 
e has the form LAMBDA(- - -) 
(VAL-REC(%,7,€), A,T) — T'{a 4 7} 


(VALREC) 


The bound name z is visible during the typechecking of the right-hand side e, but 
for safety, x must not be evaluated within e until after e’s value has been stored in x. 
Restricting e to have the form of a LAMBDA prevents e from evaluating z, even if 
the body of the LAMBDA mentions x.° 

A top-level expression is syntactic sugar for a binding to it. 


(vAL(it,e), A,T) > I’ 
(eExP(e), A,T) > I’ 


(EXP) 


A DEFINE is syntactic sugar for a suitable VAL-REC. Indeed, Typed juScheme has 
VAL-REC only because it is easier to typecheck VAL-REC and LAMBDA independently 
than to typecheck DEFINE directly. 


(VAL-REC(f, 71 X +++ X T 7 T,LAMBDA((21:71,---,2%n : Tr), €)), A,T) 3 I’ 
(DEFINE(f,7, (@1 : 71,---,2n: Tn), €),A,T) >I’ 


(DEFINE) 


Type checking 


The rules above are to be implemented by a type checker, which I hope you will 
write (Exercise 19). Type checking requires an expression or definition, a type en- 
vironment, and a kind environment. Calling typeof(e, A, I) should return a r 
such that | e : 7, or if no such 7 exists, it should raise the exception TypeError. 
Calling typdef(d, A, I) should return a pair (I’, s), where (d, A,T) — I’ and 
8 is a string that represents the type of the thing defined. 

366. (type checking for Typed Scheme [prototype] 366)= 

typeof : exp * kind env * tyex env -> tyex 

typdef : def * kind env * tyex env -> tyex env * string 


fun typeof _ = raise LeftAsExercise "typeof" 
fun typdef _ = raise LeftAsExercise "typdef" 


5In a lazy language like Haskell, a right-hand side is not evaluated until its value is needed, so a 
definition like (val-rec [x : int] x) is legal, but evaluating x produces an infinite loop (sometimes 
called a “black hole.”) 


Table 6.4: Correspondence between Typed juScheme’s type system and code 


Type system Concept Interpreter 
d Definition def (page 361) 
€ Expression exp (page 361) 
iL Name name (page 303) §6.6.6 
Type equivalence 
a Type variable name (page 303) and type-variable 
T Type tyex (page 357) renaming 
K Kind kind (page 355) 367 
Tr Type environment tyex env (pages 304 and 357) 
A Kind environment kind env (pages 304 and 355) 
AkFT:k Kind checking kindof(t, A) = &, also 
kind T = & (page 378) 
7Twhere AF 7:: x Kind checking asType(T, A) (page 380) 
A,Tre:r Typecheck e typeof(e, A, [) = 7, and often 
ty e = T (left as an exercise, 
page 366) 
(d,A,T) +I’ Typecheck d typdef(d, A, T) = (I, s) (left as 
an exercise, page 366) 
ftv(r) Free type variables freetyvars 7 (page 371) 
ftv(T) Free type variables freetyvarsGamma I (page 372) 
Tlawv 7’ ar das: tysubst(T, {a+ 7'}) (page 374) 
Va .T becomes Instantiation instantiate(Va.7, [7T'], A) 
Tlatw 7] (page 376) 
T=T' Type equivalence eqType(T, T’) (page 370) 
xz € doml Definedness find (x, I) terminates without 
raising an exception (page 305) 
T(a) Type lookup find (x, T) (page 305) 
T{a+4 7} Binding bind (x, 7, I) (page 305) 
T{ap ,...,2n'> Tm} Binding I <+> mkEnv (21,...,2n, 
T1,-++,Tn) (page 305) 
int, bool,... Base types inttype, booltype, ... (page 381) 

T, X ++: XTp,—> 7 Function type FUNTY([71,---; Tn], T) (page 357) ae Be ye 
type exp 361la 
type kind 355a 
LeftAsExercise 

To implement these functions, you need function eqType, which tells when two S213b 
type tyex 357a 


types are equivalent, and function instantiate, which instantiates polymorphic 


types. Equivalence and instantiation are the topics of the next two sections. 


6.6.6 Type equivalence and type-variable renaming 


Many typing rules require that two types be the same. For example, in an if expres- 
sion, the types of the two branches have to be the same. And in Typed puScheme, 
two types may be considered the same even if they are not identical. For exam- 
ple, types Va .a@ list — int and VG. 6 list — int are considered to be the 
same—the names of bound type variables a and £ are irrelevant. The names are ir- 
relevant because the only thing we can do with a quantified type is substitute for its 
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bound type variables, and once we have substituted, the names are gone. In gen- 
eral, type Vay . 71 is equivalent to Vaz . 72 if for every possible 7, 7[a1 +> T] is 
equivalent to T2[@2 +> T]. When two types are equivalent, we write T = 7’. 

A type-equivalence relation must preserve type soundness. Soundness says 
that well-typed programs don’t go wrong; in particular, if a well-typed program has 
a subterm e of type T, a type-soundness theorem allows us to change the program 
by substituting any other term e’ of the same type r. While the changed program 
might produce a different answer, it’s still guaranteed not to go wrong. And if there 
is an equivalent type, say 7’ = T, we must also be allowed to substitute any term 
e” of type 7’, and the program must still not go wrong. 


The names of parameters are irrelevant 


In Typed jScheme, two types are equivalent if one can be obtained from the other 
by renaming bound type variables. And a bound type variable originates as a type 
parameter in a type-lambda. Bound type variables and type-lambdas may seem 
new and mysterious, but just like the parameters in an ordinary lambda, the pa- 
rameters in a type-lambda can be renamed without changing the meaning of the 
code. Let’s look at examples of each. 

In (lambda (x) (+x1n)), renaming x to y doesn’t change the meaning of the 
code: 


(lambda (x) (+ x n)) ; two equivalent uScheme functions 
(lambda (y) (+ y n)) 


Andina (type-lambda ['a] ---), similarly renaming 'a to 'b doesn’t change the 
meaning of the code: 
368a. (transcript 357b) += 1362 368c> 
-> (val idl (type-lambda ['a] (lambda ([x : 'a]) x))) 
idi : (forall ['a] ('a -> 'a)) 
-> (val id2 (type-lambda ['b] (lambda ([x : 'b]) x))) 
id2 : (forall ['b] ('b -> 'b)) 
The renaming gives functions id1 and ide types that are syntactically different, but 
still equivalent: one type is obtained from the other by renaming 'a to 'b. In fact, 
function id1 has every type that can be obtained from (forall ['a] ('a-> 'a)) 
by renaming 'a. Here is some evidence: 
368b. (type-tests-id.tus 368b) = 
(check-type id1 (forall ['a] ('a -> 'a))) 
(check-type id1 (forall ['b] ('b -> 'b))) 
(check-type id1 (forall ['c] ('c -> 'c))) 
368c. (transcript 357b) += <1368a 373a> 
-> (use type-tests-id.tus) 
All 3 tests passed. 


When can’t we rename a bound type variable? Imagine a function that takes a 
value of any type and returns a value of type 'c; that is, imagine a function of type 
(forall ['a] ('a-> 'c)). Renaming 'a to 'b doesn't change the type: 


(forall ['a] ('a -> 'c)) ; equivalent types 
(forall ['b] ('b -> 'c)) 


But renaming 'ato 'c does change the type: 
(forall ['c] ('c -> 'c)) ; not equivalent to the first two 


As illustrated above, type (forall ['c] ('c -> 'c)) is the type of the identity func- 
tion, and it’s not the same as (forall ['a] ('a-> 'c)). Functions of these types 


have to behave differently: a function of type (forall ['a] ('a-> 'c)) ignores its 
argument, and a function of type (forall ['c] ('c -> 'c)) returns its argument. 

That last renaming is invalid because it captures type variable 'c: 'c is free in 
the original type but bound in the new type, so its meaning has been changed. 
Whenever we rename a bound type variable, whether it is bound by forall 
or type-lambda, we must not capture any free type variables. (The same re- 
striction applies to the formal parameters of a lambda expression; for example, 
x can be renamed to y in (lambda (x) (+x n)), but x can’t be renamed to n; 
(lambda (n) (+n n)) is not the same function!) Also, when we substitute a type T 
for a free type variable, we must not capture any free type variables of T. 


Soundness of type equivalence in Typed jsScheme 


Why is it sound to consider types equivalent if one can be obtained from the other 
by renaming bound type variables? Because if two types differ only in the names 
of their bound type variables, no combination of instantiations and substitutions 
can distinguish them. To show what it means to distinguish types by instantiation 
and substitution, let’s compare the three types above. First I instantiate each type 
at T,, then I substitute 72 for free occurrences of 'c: 


Original type After instantiation After substitution 
(forall ['a] ('a-> 'c)) (7 -> 'c) (71 -> T2) 
(forall ['b] ('b-> 'c)) (7 -> 'C) (71 -> T2) 
(forall ['c] ('c -> 'c)) (7 -> 71) (7 -> 71) 


No matter how 7, and 72 are chosen, the first two forall types produce identical 
results. But when 7; and 72 are chosen intelligently—int and boo1 will do—the first 
two forall types become (int -> bool), but the third one becomes (int -> int), 
which is different. 


Rules and code for type equivalence 


Typed pScheme’s type equivalence t = 1’ is defined by a proof system. A type 
variable or type constructor is equivalent to itself, and type equivalence is structural 
through function types, constructor applications and quantifications. 


EQUALVARIABLES EQUALCONSTRUCTORS 
a=a =p 
EQUIVFUNS 
%=T, 1<i<n rer 
TEX XTi OTST X XT ST 
EQUIVAPPLICATIONS EQUIVQUANTIFIEDS 
h=T%,1<i<n rer T=T7' 
= / / / se / 
(T1,---57) T = (T],---5TR) T Vay,...,Qn.T=Vay,...,Qn.T 


These five rules make syntactically identical types equivalent. The next rule makes 
two types equivalent if one is obtained from the other by renaming a bound type 
variable. Provided new type variable / is not free in 7, any a; can be renamed to (3: 


B ¢€ ftv(r) BE {a1,..-,An} 
VO1,.--,An-.T =Va,...,Qj-1, 8, Ai41,01,---,AQn-Tlai > 8] 
(EQUIVRENAMED) 
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The second premise 3 ¢ {a1,...,@,} ensures that even after the renaming, the 
bound type variables are all distinct. 

Like any equivalence relation, type equivalence is symmetric. (Symmetry per- 
mits variables to be renamed on the left side of the = sign, for example.) 


T=T' 
(SYMMETRY) 


T=T 
Type equivalence is also reflexive and transitive (Exercise 24). 

Typed puScheme’s type-equivalence relation is implemented by function eqType. 
Given types formed with TYVAR, TYCON, CONAPP, or FUNTY, function eqType imple- 
ments the unique rule that applies to the form. 
370a. (type equivalence for Typed j1Scheme 370a)= ($405a) 


eqlype : tyex * tyex -> bool 
eqlypes : tyex list * tyex list -> bool 


(infinite supply of type variables $417e) 
fun eqType (TYVAR a, TYVAR a') 
eqlype (TYCON c, TYCON c') c= c! 

eqlype (CONAPP (tau, taus), CONAPP (tau', taus')) = 

eqlype (tau, tau') andalso eqTypes (taus, taus') 

eqlype (FUNTY (taus, tau), FUNTY (taus', tau')) = 

eqlype (tau, tau') andalso eqTypes (taus, taus') 

eqlype (FORALL (alphas, tau), FORALL (alphas', tau')) = 

(Boolean saying if FORALL (alphas, tau) = FORALL (alphas', tau') 370b) 
eqlype _ = false 

and eqlypes (taus, taus') = ListPair.allEq eqType (taus, taus') 


az=a' 


Given types formed with FORALL, say Vaj,...,Q@, .7 and Va";,...,an . 7’, 
eqType first renames the bound type variables on both sides to 31,..., Gy. Itthen 
compares the renamed types: 

VB1,.+-; Bn. Tia O B1,...,Qn > By] and 
VB1,---;Bn- Ta  B1,-.-,0, 8 Br}. 
According to rule EQUIVQUANTIFIEDS, the comparison succeeds if the first body 
type, Tla1 +> B1,.--,Qn 9 Bn], is equivalent to 7’ la, HH B1,...,a%, + Br}. 


Because all the a,’s and a/’s are renamed, no 3; can collide with an existing 
Qu OF OY. 
370b. (Boolean saying if FORALL (alphas, tau) = FORALL (alphas', tau') 370b)= (370a) 

let fun ok a = 
not (member a (freetyvars tau) orelse member a (freetyvars tau')) 
val betas = streamTake (length alphas, streamFilter ok infiniteTyvars) 
in length alphas = length alphas' andalso 
eqlype (rename (alphas, betas, tau), rename (alphas', betas, tau')) 
end 
Type variables 3,,..., 3, (oetas) are drawn from an infinite stream. Streams and 
stream operators, as well as the particular stream infiniteTyvars, are defined 
in the Supplement. Because the stream contains infinitely many type variables, 
of which only finitely many can be free in 7 or 7’, it is guaranteed to hold n good 
ones. 

Function rename is implemented using substitution; both rename and tysubst 
are defined in the next section. 

Function eqType can be used in the implementation of any typing rule that re- 
quires two types to be the same. To formalize the use of equivalence instead of 
identity, I extend the type system with the following rule, which says that if e has a 
type, it also has any equivalent type. 


A,TrFe:r T=T' 


A,TFe:7’ MEOUIV) 


6.6.7  Instantiation and renaming by capture-avoiding substitution 


Capture-avoiding substitution is tricky—even eminent professors sometimes get it 
wrong. To study it, we first need to get precise about free and bound type variables. 


Free and bound type variables 


Type variables may occur free or bound, and we substitute only for free occurrences. 
A free type variable acts like a global variable; a bound type variable acts like a 
formal parameter. And a binding occurrence is an appearance next to a forall. All 
three kinds of occurrences are shown in this example type: 


Example type A ('c -> (forall ['a] ('a-> 'c))) 
Free occurrence of 'cinA ('c -> (forall ['a] ('a-> 'c))) 
Binding occurrence of 'ainA ('c-> (forall ('a) ('a->'c))) 
Bound occurrence of 'ainA ('c -> (forall ('a) ('a-> 'c))) 
Free occurrence of 'cinA ('c -> (forall ('a) ('a->'c))) 


As the wording suggests, “free” and “bound” are not absolute properties; they are 
relative to a particular type. For example, type variable 'a occurs bound in type 
(forall ['a] ('a-> 'c)), butit occurs free in type ('a -> 'c). 

Free type variables can be specified by a proof system. The judgment of the 


system is| a € ftv(T) |, which means “a is free in rT.” The proof system resembles 


the proof system for free term variables in Section 5.6 (page 316): 


a € ftv(7;) a € ftv(r) 
a € ftv(a) a € ftv((™1,---;T) T) a € ftv((T1,.--; Tn) rT) 
a € ftv(7;) a € ftv(r) 
a € ftv(T X +++ X Tr > T) a € ftv(7, X--»X TT). 


a € ftv(r) axa, 1<i<n 
a € ftv(Vay,...,@n,.T) 


Also, if a; € ftv(7), then a; is boundin Vaj,..., Qn .T. 

The free type variables of a type are computed by function freetyvars. Bound 
type variables are removed using diff. Using foldl, union, diff, and reverse puts 
type variables in the set in the order of their first appearance. 


371. (sets of free type variables in Typed psScheme 371) = ($405a) 372> 
fun freetyvars t = freetyvars : tyex -> name set 
let fun free (TYVAR v, ftvs) = insert (v, ftvs) 
| free (TYCON _, ftvs) = ftvs 


| free (CONAPP (ty, tys), ftvs) = foldl free (free (ty, ftvs)) tys 
| free (FUNTY (tys, ty), ftvs) = foldl free (free (ty, ftvs)) tys 
| free (FORALL (alphas, tau), ftvs) = 
union (diff (free (tau, emptyset), alphas), ftvs) 
in reverse (free (t, emptyset)) 
end 


“Binding occurrence” doesn’t need a proof system; binding occurrences are those introduced by V. 
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The free type variables of a type environment, which are needed to enforce 
the side condition in rule TYLAMBDA page 365, are computed by calling function 
freetyvarsGamma. 


372. (sets of free type variables in Typed Scheme 371) += ($405a) 1371 


freetyvarsGamma : tyex env -> name set 


fun freetyvarsGamma Gamma = 


foldl (fn ((x, tau), ftvs) => union (ftvs, freetyvars tau)) emptyset Gamma 


Substitution is for free variables only 


Free occurrences govern the behaviors of both renaming and substitution. When 
we rename a bound type variable in a forall, we rename only the free occurrences 
in the body of the forall. And when we substitute for a type variable is substi- 
tuted for, we substitute only for free occurrences. Restricting substitution to free 
variables may seem arbitrary, but it is motivated by a principle of observational 
equivalence: If types 7; and 72 are equivalent, and if 7 is substituted for a in both 
types, then the resulting types 7 [a +> T] and 72[a +> 7] should still be equivalent. 
For example, here are two equivalent types: 


('c -> (forall ['a] ('a -> 'c))) ; example A 
C'c -> (forall ['b] ('b -> 'c))) ; example B 


Suppose I wish to substitute 'c for 'b. In example A, there are no occurrences of 'b, 
and nothing happens. What about example B? There are no free occurrences of 'b, 
just one binding occurrence and one bound occurrence. So also, nothing happens! 
And when nothing happens to two equivalent types, the results are still equivalent. 

If I mistakenly substitute for the binding occurrence of 'b or for the bound 
occurrence of 'b, or for both, the resulting types are no longer be equivalent to ex- 
ample type A. 


('c -> (forall ['c] ('b -> 'c))) 7; WRONG B1 
('c -> (forall ['b] ('c -> 'c))) 7; WRONG B2 
C'c -> (forall ['c] ('c -> 'c))) 7; WRONG B3 


Each mistake goes wrong in a different way: 


B1. I substitute for the binding occurrence of 'b but not for the bound occur- 
rence in the body. If Inow rename the bound type variable 'c to 'a, I get the 
type ('c -> (forall ['a] ('b -> 'a))). The outer part now matches exam- 
ple A, but the but inner function type ('b -> 'a) is not equivalent to exam- 
ple A’s ('a -> 'c). 


B2. I substitute for the bound occurrence of 'b in the body but not for the bind- 
ing occurrence in the forall. If I now rename the bound type variable 'b 
to 'a, Iget ('c -> (forall ['a] ('c -> 'a))), and again, inner function type 
('c -> 'c) is not equivalent to example A’s ('a-> 'c). 


B3. I substitute for both binding and bound occurrences of 'b. If I now rename 
the bound type variable 'c to 'a, I get ('c -> (forall ['a] ('a->'a))), 
and again, inner function type ('a-> 'a) is not equivalent to example A’s 
('a->'c). 


When I’m substituting for 'b and I hit a forall that binds 'b, I must leave it alone. 
If that thought makes you uneasy, imagine “leave it alone” as a three-step proce- 
dure: 


1. First rename the bound 'b to 'z, which preserves equivalence. 


2. Now substitute 'c for 'b. But there are no 'b’s—it’s just like example A! 
3. Finally rename the bound 'z back to 'b, which again preserves equivalence. 


Here’s one more example of not substituting for a bound type variable. I define 

a polymorphic value strange of type Va .Va.a— a: 
373a. (transcript 357b) += <1368c 373b> 

-> (val strange 

(type-lambda ['a] 
(type-lambda ['a] 
(lambda ([x : 'a]) x)))) 

strange : (forall ['a] (forall ['a] ('a -> 'a))) 
To instantiate strange at int, I strip the outer Va., and I substitute int for free 
occurrences of win Va.a@ — qa. But there are no free occurrences! Type variable a 
is bound in Va . a — a, and substituting int yields Va .a — a: 
373b. (transcript 357b) += 1373a 

-> [@ strange int] 

<function> : (forall ['a] ('a -> 'a)) 


It’s strange but true. 


Substitution avoids capturing variables 


Substitution must not only avoid substituting for bound occurrences; it must also 
avoid changing a free occurrence to a bound occurrence. That is, supposing 7 is 
substituted for 'c, every type variable that is free in 7 must also be free in the result. 
As an example, let us substitute (list 'b) for 'c in example types A and B: 


C'c -> (forall ['a] ('a -> 'c))) ; example A 

C'c -> (forall ['b] ('b -> 'c))) ; example B 

((list 'b) -> (forall ['a] ('a -> (list 'b)))) ; A substituted 
((list 'b) -> (forall ['b] ('b -> (list 'b)))) ; B substituted WRONG 


In both examples, we substitute for two free occurrences of 'c. The type we sub- 
stitute has one free occurrence of 'b. In example A, the result has, as expected, 
two free occurrences of 'b, But in example B, the second free occurrence of 'b has 
become a bound occurrence. We say variable 'b is captured. 

Capture is a problem in any computation that involves substitutions—think 
macros—and the problem is one we have solved before: it’s the problem of the 
faulty let sugar for | | in Section 2.13.3 (page 165). The faulty sugar suggests that 
(|| €1 €2) be implemented by substituting for e; and e€2 in this template: 


(let ([x e,]) (if x x e€2)). 


The substitution fails if x appears as a free variable in eg—when €2 is substituted 
into the template for | |, variable x is captured and its meaning is changed. Capture 
is avoided by renaming the bound variable x to something that is not free in e2. 

A polymorphic type system avoids capture in the same way: by renaming a 
bound type variable. And in the type system, renaming is easy to justify: when we 
rename, instead of substituting into example type B, we are substituting into an 
equivalent type. In the example above, the only type variable bound in Bis 'b, and 
we rename it to 'z: 


C'c -> (forall ('z) ('z -> 'c))) ; equivalent to B 
((list 'b) -> (forall ('z) ('z -> (list 'b)))) ; and now substituted 


Now the substitution is correct, and the result is equivalent to A substituted. 
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Specifying and implementing substitution 


Let’s generalize from the example to a specification. To substitute one type 7 for 
free occurrences of type variable a, without allowing any variable to be captured, 


the judgment form is | r'[a +> 7] = 7’ |. Itis pronounced “r7’ with a going to 7 is 


equivalent to 7’”.” 


Substitution for a changes only a. And it preserves the structure of construc- 
tors, constructor applications, and function types. 


alaw tTr]=T alan tT]=a 


(LX XT a T'lavn tle tilant] x: x tlant]or/lan tl 


Substitution into a quantified type may substitute for free variables only, and it may 
not capture a free type variable of T: 


a¢ {ay,...,@} — ftv(r)N {a4,...,an} =9 
(Va1,...,Qn.7')[a 7] =Vai,..., Qn. (7/[a + 7)) 


The second premise prevents variable capture. Substitution can proceed without 
capture by substituting into an equivalent type: 


aera 2 
on == 


Tlaw tT] =7"[aH 7] 
Substitution for a bound variable has no effect: 


(Va1,...,Qn.7’)[aj > 7] = (Var,...,Qn.7’) 

In Typed pzScheme, substituting for a single type variable isn’t enough; instan- 
tiation substitutes for multiple type variables simultaneously. A substitution is rep- 
resented by an environment of type tyex env, which is passed to function tysubst 
as parameter varenv. This environment maps each type variable to the type that 
should be substituted for it. If a type variable is not mapped, substitution leaves it 
unchanged. 


374. (capture-avoiding substitution for Typed Scheme 374) = (S405a) 375¢> 


tysubst : tyex * tyex env -> tyex 
fun tysubst (tau, varenv) = subst : tyex ~> tyex 
let (definition of renameForallAvoiding for Typed puScheme (left as an exercise)) 

fun subst (TYVAR a) = (find (a, varenv) handle NotFound => TYVAR a) 
subst (TYCON c) = (TYCON c) 
| subst (CONAPP (tau, taus)) = CONAPP (subst tau, map subst taus) 
| subst (FUNTY (taus, tau)) = FUNTY (map subst taus, subst tau) 
| subst (FORALL (alphas, tau)) = 

(use varenv to substitute in tau; don’t capture or substitute for any alphas 375b) 

in subst tau 


end 


Substitution into a quantified type must not substitute for a bound variable and 
must avoid capturing any variables. Postponing for the moment the issue of cap- 
ture, tysubst prevents substitution for a bound type variable by extending varenv 
so that each bound type variable is mapped to itself: 


375a. (substitute varenv in FORALL (alphas, tau) (OK only if there is no capture) 375a) = (375b) 


let val varenv' = varenv <+> mkEnv (alphas, map TYVAR alphas) 
in FORALL (alphas, tysubst (tau, varenv')) 
end 


To avoid capture, tysubst identifies and renames bindings that might capture 
a variable. The scenario has three parts: 


+ Atype Tnew is substituted for a variable that appears free in Vaj,...,Qp,.T. 


+ Among the free variables of type Tnew is one of the very type variables a; that 
appears under the V. 


* To avoid capturing a;, the bound aq; has to be renamed. 


Below, «;’s that have to be renamed are put ina set called actual_captures. Ifthe 
set is empty, the code above works. Otherwise, the variables in actual_captures 
are renamed by function renameForallAvoiding. 


375b. (use varenv to substitute in tau; don’t capture or substitute for any alphas 375b)= —(374) 
let val free = freetyvars (FORALL (alphas, tau)) 
val new_taus = map (subst o TYVAR) free 


val potential_captures = foldl union emptyset (map freetyvars new_taus) 
val actual_captures = inter (potential_captures, alphas) 
in if null actual_captures then 
(substitute varenv in FORALL (alphas, tau) (OK only if there is no capture) 375a) 
else 
subst (renameForallAvoiding (alphas, tau, potential_captures) ) 
end 


When capture may occur, function renameForallAvoiding renames the alphas 
to avoid potentially captured variables. It must return a type that is equivalent 
to FORALL (alphas, tau) but that does not result in variable capture. In detail, 
renameForallAvoiding([a1,...,Q@n],7,C) returns atype V3;,..., 8,.7' that has 
these properties: 


YB1,..-,Bn.T =Va1,...,Qn-T, 


{B1,---,Bn} AC =O. 


The implementation of renameForallAvoiding is left to you (Exercise 28). 


Renaming and instantiation 


Renaming is a special case of substitution. It substitutes one set of variables for 
another. 


375¢. (capture-avoiding substitution for Typed jScheme 374) += (S405a) 1374 376ab 


rename : name list * name list * tyex -> tyex 


fun rename (alphas, betas, tau) = 
tysubst (tau, mkEnv (alphas, map TYVAR betas)) 


Instantiation is also implemented by substitution. It builds a type environment 
that maps formal type parameters to actual type parameters. Most of the code en- 
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<+> 305f 
CONAPP 357a 
emptyset $217b 
find 305b 
FORALL 357a 
freetyvars 371 
FUNTY 357a 
inter $217b 
mkEnv 305e 


type name 303 
NotFound 305b 


renameForall- 
Avoiding 397 
TYCON 357a 
type tyex 357a 
TYVAR 357a 
union $217b 


forces restrictions: only quantified types may be instantiated, only at actual types 
of kind TYPE, and only with the right number of types. 
376a. (capture-avoiding substitution for Typed t1Scheme 374) += ($405a) <375¢ 


instantiate : tyex * tyex list * kind env -> tyex 
List.find : ('a -> bool) -> 'a list -> 'a option 
fun instantiate (FORALL (formals, tau), actuals, Delta) = 
(case List.find (fn t => not (eqKind (kindof (t, Delta), TYPE))) 
actuals 
of SOME t => raise TypeError 


Type systems for 


Impcore and Scheme ("instantiated at type constructor ‘" A 


376 typeString t 4 "', which is not a type") 
| NONE => 
(tysubst (tau, mkEnv (formals, actuals) ) 
handle BindListLength => 
raise TypeError 
"instantiated polymorphic term at wrong number of types")) 
| instantiate (tau, _, _) = 
raise TypeError ("tried to instantiate term " A 


"of non-quantified type " A typeString tau) 


The Standard ML function List. find takes a predicate and searches a list for an 
element satisfying that predicate. 


6.6.8 Subverting the type system through variable capture 


We avoid variable capture because if capture were permitted, the type system could 
be subverted: a value of any type could be cast to a value of any other type. 

In a world where capture isn't avoided, subverting the type system requires just 
two type-lambdas and two type variables. We first define a Curried function that 
takes an argument, takes a function to apply to the argument, then returns the ap- 
plication. In untyped pScheme, the code might look like this: 
376b. (uScheme transcript 376b)= 

-> (val flip-apply (lambda (x) (lambda (f) (f x)))) 
-> ((flip-apply '(a b c)) reverse) 
(c b a) 
-> (val apply-to-symbols (flip-apply '(a b c))) 
-> (apply-to-symbols reverse) 
(c b a) 
-> (apply-to-symbols cdr) 
(b c) 
To add types, we give x type § and f type 8 — a, so flip-apply has type 


flip-apply : V8.8 — (Va.(8 > a) > a). 


This perfectly reasonable type implies that if we supply a value of type G anda 
function of type 6 — a, we can get a value of type a. Function flip-apply can be 
defined with this type without any variable capture (Exercise 33). 
376c. (variable-capture transcript 376c)= 376d> 
-> (val flip-apply (typed version of flip-app]y (left as an exercise)) ) 
flip-apply : (forall ['b] ('b -> (forall ['a] (('b -> 'a) -> 'a)))) 

Given flip-apply, I poke at the hole in the type system: I try to substitute 'a 
for 'b andthen 'b for 'a. Ifthe first substitution is done incorrectly, 'ais captured, 
and I can define a polymorphic function with a senseless type: 
376d. (variable-capture transcript 376c) += <1376c 377a> 

-> (type-lambda ['a] [@ flip-apply 'a]) ; variable 'a is captured! 
<function> : (forall ['a] ('a -> (forall ['a] (('a -> 'a) -> 'a)))) 


This anonymous function, after it is instantiated and applied, will return a result 
of type Va . (a + a) > a. That result can be instantiated at any type 7. If I then 
supply an identity function of type 7 — T, I get back a value of type 7. Which is 
nonsense! A single polymorphic function cannot manufacture a value of an arbi- 
trary type T, for any T. 

Having captured 'a, I make the nonsense more obvious by instantiating the 


problematic result type at 'b: §6.6.9 


377a. (variable-capture transcript 376c) += <1376d 377b> Preventing capture 
-> (val pre-cast 
(type-lambda ['a 'b] 
(lambda ([x : 'a]) 377 
[@ ({@ flip-apply 'a] x) 'b]))) 
pre-cast : (forall ['a 'b] ('a -> (('b -> 'b) -> 'b))) 


with type-lambda 


Now you modify pre-cast by supplying an identity function in the right place (Ex- 
ercise 33 again). Use flip-apply to define a function cast of type Va, 8 .a — 2: 
377b. (variable-capture transcript 376c) += <1377a 377¢> 
-> (val cast (definition of cast (left as an exercise)) ) 
cast : (forall ['a 'b] ('a -> 'b)) 

Function cast can be used to change a value of any type to any other type. For 
example, we can “make a function” out of the number 42. doesn’t work. When we 
apply the supposed function, the evaluator reports a bug in the type checker. 
377¢. (variable-capture transcript 376c) += <1377b 

-> ([@ cast int (int -> int)] 42) 

42 : (int -> int) 

-> (([@ cast int (int -> int)] 42) 0) 

bug in type checking: applied non-function 


6.6.9 Preventing capture with type-lambda 


To make the type system sound, it’s not enough to substitute correctly into quan- 
tified types; we must also take care when introducing them. A quantified type is 


‘ ‘ BindListLength 
introduced by type-lambda, and to ensure soundness, type-lambda restricts the 205e 
names of its formal (type) parameters: cdr P 162a 
type env 304 
a, ¢ftv(T), l<i<n  Afay:,...Qn, i *}, DF e:7 eqKind 355b 
A, TF TYLAMBDA(a Qn,e) : Va Ces By EEE EDS ee te 
: BO EL EAS Pt type kind  355a 
. ‘ kindof 378b 
The restriction a; ¢ ftv(I’) prevents a form of variable capture. ast, 205e 
The restriction is necessary because a polymorphic term TYLAMBDA(aq, e) can reverse B 
be instantiated by substituting any type 7 for a. And if a already stands for some- type tyex — 357a 
thing else, there’s trouble. As a first example, I can make a already stand for the Een oe 
type of a term variable x; I wrap a type-lambda around a lambda: auesinins Sail 


tysubst 374 
(type-lambda ['a] (lambda ([x: 'a])...)) 


Within the ..., the typing environment binds x to 'a, so 'a is a free type variable 
of I’. Suppose an inner type-lambda were permitted to bind 'a for a second time: 


(type-lambda ['a] (lambda ([x : 'a]) 
(type-lambda ['a] (lambda ([y: 'a]) ...)))) 


In the position of the ... in the new example, it looks like x and y both have the 
same type, but they can be given different types. That puts a hole in the type system. 
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For example, two values can be compared for equality regardless of their types: 
378a. (transcript with no restriction on type-lambda 378a)= 
-> (val bad= (type-lambda ['a] (lambda ([x : 'a]) 
(type-lambda ['a] (lambda ([y : 'a]) 
([@ = 'a] x y)))))) 
bad= : (forall ['a] ('a -> (forall ['a] ('a -> bool)))) 
-> (val worse= (type-lambda ['a 'b] 
(lambda ([x : 'a] [y : 'b]) 
({[@ ([@ bad= 'a] x) 'b] y)))) 
worse= : (forall ['a 'b] ('a 'b -> bool)) 
By using a similar trick, you can make a value of any type masquerade as a value of 
any other type (Exercises 31 and 32). 


6.6.10 Other building blocks of a type checker 


The functions for equivalence, substitution, and instantiation, which are presented 
above, are all key elements of a type checker, which I hope you will write (Exer- 
cise 19). When you do, you can take advantage of some more useful functions, 
which are presented below. 


Ensuring well-formed types: Kind checking 


A type in the syntax, like the type of a parameter in a lambda abstraction, can’t be 
trusted—it has to be checked to make sure it is well formed. In Typed psScheme, 
a tyex is well formed if it has a kind (Section 6.6.2, page 355). The kind is com- 
puted by function kindof, which implements the kinding judgment A F 7 :: kK. 
This judgment says that given kind environment A, type-level expression 7 is well 
formed and has kind k. Given A and 7, kindof(7, A) returns a « such that 
At 7 :: k, or if no such kind exists, it raises the exception TypeError. 


378b. (kind checking for Typed Scheme 378b) = (S405a) 380a> 
fun kindof (tau, Delta) = kindof : tyex * kind env -> kind 
let (definition of internal function kind 378c) |kind : tyex -> kind 


in kind tau 
end 
The internal function kind computes the kind of tau; the environment Delta is 
assumed. Function kind implements the kinding rules in the same way that typeof 
implements the typing rules and eval implements the operational semantics. 
The kind of a type variable is looked up in the environment. 


aé€domA 

AF Tyvar(a) :: A(q@) 

Thanks to the parser in Section Q.6, the name of a type variable always begins with 
a quote mark, so it is distinct from any type constructor. 

378c. (definition of internal function kind 378c)= (378b) 378d> 

fun kind (TYVAR a) = 
(find (a, Delta) 
handle NotFound _ => raise TypeError ("unknown type variable " 4 a)) 


(KINDINTROVAR) 


The kind of a type constructor is also looked up. 


we dome (KINDINTROCON) 
AF TYCON() :: A(t) 
378d. (definition of internal function kind 378c) += (378b) <378c 379a> 


| kind (TYCON c) = 
(find (c, Delta) 
handle NotFound _ => raise TypeError ("unknown type constructor " A c)) 


The kind of a function type is x, provided that the argument types and result 
type also have kind «. 


AFR: 1<i<n AFT: * 
(KINDFUNCTION) 
AE TX +++ X TOT 
379a. (definition of internal function kind 378c) += (378b) <378d 379b> 


| kind (FUNTY (args, result)) = 
let fun badKind tau = not (eqKind (kind tau, TYPE)) 
in if badKind result then 
raise TypeError "function result is not a type" 
else if List.exists badKind args then 
raise TypeError "argument list includes a non-type" 
else 
TYPE 
end 


The argument types are inspected using Standard ML function List.exists, which 
corresponds to the jzScheme function exists?. 

Provided that an applied constructor has an arrow kind, the kind of its appli- 
cation is the arrow’s result kind. The kinds of the argument types must be what is 
expected from the arrow’s arguments. 


AFT Ky XX Kn SK AFR 2k, 1L<i<n 
AF conapp(, [T1,---,Tn]) 2K 


(KINDAPP) 


379b. (definition of internal function kind 378c) += (378b) <379a 379¢> 
| kind (CONAPP (tau, actuals)) = 
(case kind tau 
of ARROW (formal_kinds, result_kind) => 
if eqKinds (formal_kinds, map kind actuals) then 
result_kind 
else 
raise TypeError ("type constructor " A typeString tau A 
"applied to the wrong arguments") 
| TYPE => 
raise TypeError ("tried to apply type " A typeString tau A 
"as type constructor")) 


The kind of a quantified type is always *, provided its body also has kind x. 


Afay ii *,..., An kb} Ts 


KINDALL 
AF FORALL((Q1,..-,Q@n),T) 2: * ( ) 
The quantified variables a1, ... , @, may be used in T, so they are added to A before 
the kind of 7 is computed. 
379¢. (definition of internal function kind 378c) += (378b) <379b 


| kind (FORALL (alphas, tau)) = 

let val Delta' = 

foldl (fn (a, Delta) => bind (a, TYPE, Delta)) Delta alphas 
in case kindof (tau, Delta') 

of TYPE => TYPE 

| ARROW _ => 
raise TypeError "quantifed a non-nullary type constructor" 

end 
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Variables and parameters must have kind TYPE 


A tyex used to describe a variable or parameter must have kind TYPE. Function 
asType ensures it. 


380a. (kind checking for Typed j1Scheme 378b) += (S405a) <378b 
fun asType (ty, Delta) = asType : tyex * kind env -> tyex 
case kindof (ty, Delta) 
of TYPE => ty 
| ARROW _ => raise TypeError ("used type constructor ‘" A 


typeString ty 4 "' as a type") 


Evaluation in the presence of polymorphism 


This chapter is about types, but the code does eventually have to be evaluated. 
In Typed jzScheme, types have no effect at run time; expressions are therefore eval- 
uated using the same rules as for untyped zScheme. And there are new rules for 
evaluating type abstraction and application. These rules specify that the evaluator 
behaves as if these type abstraction and application aren't there. 


(e, p27) 4 (v, 0") 


(TYAPPLY(€,71,---,T7n),P,0) ¥ (v, 0’) 


(TYAPPLY) 


(6, po) 4 (v, 0") 


(TYLAMBDA((Q1,...,Qn),€), 2,0) 4 (v, 0°) 


(TYLAMBDA) 


This semantics is related to a program transformation called type erasure: if you 
start with a program written in Typed juScheme, and you remove all the TYAPPLYs 
and the TYLAMBDAs, and you remove the types from the LAMBDAs and the definitions, 
and you rewrite VALREC to VAL, then what’s left is a ,zScheme program. 

The evaluator for Typed Scheme resembles the evaluator for Scheme in 
Chapter 5. The code for the new forms acts as if TYAPPLY and TYLAMBDA arent there. 
380b. (alternatives for ev for TYAPPLY and TYLAMBDA 380b) = (S411b) 

| ev (TYAPPLY (e, _)) = eve 
| ev (TYLAMBDA (_, e€)) = eve 
The rest of the evaluator can be found in Appendix Q. 

Definitions are evaluated slightly differently than in untyped Scheme. As in 
Typed Impcore, the type system and operational semantics cooperate to ensure 
that no definition ever changes the type of an existing name. In Typed Impcore, 
the assurance is provided by the type system: it permits a name to be redefined 
only when the existing type is preserved. In Typed Scheme, the assurance is pro- 
vided by the operational semantics: as in Exercise 46 from Chapter 2, evaluating 
a definition always creates a new binding. In a VAL binding, the right-hand side 
is evaluated in the old environment; in a VAL-REC binding, the right-hand side is 
evaluated in the new environment. The type system guarantees that the result of 
evaluation does not depend on the unspecified value with which ¢ is initialized. 


€¢ domo 
(e, P; o) Y (v, a’) 
(Wail, €),p,0) + (plas U},a{0 of) ma 
€¢ domo 
(e, p{x + L},0{0 unspecified}) |) (v, 0’) (VAL-REC) 


(VAL-REC(x,T, €), p,7) > (p{a > bh, a {lH v}) 
These rules are implemented in Appendix Q. 


Primitive type constructors of Typed Scheme 


The types of the primitive functions have to be written using ML code inside the 
interpreter, but the raw representation isn't easy to write. For example, the type of 
cons is represented by this enormous constructed value: 


FORALL (["'a"], 
FUNTY ([TYVAR "'a", CONAPP (TYCON "list", [TYVAR "'a"])]), 
CONAPP (TYCON "list", [TYVAR "'a']))) 


To make such values easier to construct, I provide these representations: 


381a. (types for Typed puScheme 357a) += (S405a) <1357a 
val inttype = TYCON "int" inttype : tyex 
val booltype = TYCON "bool" booltype : tyex 
val symtype = TYCON "sym" symtype : tyex 
val unittype = TYCON "unit" unittype : tyex 
val tvA = TYVAR "'a" tvA : tyex 
fun listtype ty = CONAPP (TYCON "list", [ty]) listtype : tyex -> tyex 


Each of these type constructors creates a type or types that are inhabited by cer- 
tain forms of value. For example, types int and bool are inhabited by values of 
the form NUM n and BOOLV 5; that’s what eval returns when interpreting an expres- 
sion of type int or bool. What about type unit? That type also needs an inhabitant, 
which is defined here: 


381b. (utility functions on values (Scheme, Typed Scheme, nano-ML) 381b) = (S379 S405a) 
val unitVal = NIL unitVal : value 


This conventional inhabitant is used to represent every value of type unit, which 
ensures that when comparing two unit values, the primitive = function always re- 
turns #t. 


Selected primitive functions of Typed jsScheme 


Each primitive function has a name, a value, and a type. Most of them appear in 
the Supplement, but to show you how primitives are defined, a few appear here. 

Asin Chapter 5, primitive values are made using functions unaryOp, binaryOp, 
and arithOp. But if something goes wrong at run time, the Typed jsScheme ver- 
sions don’t raise the RuntimeError exception; they raise BugInTypeChecking. And 
Typed yuScheme’s primitives need types! As the type of the arithmetic primitives, 
I define arithtype. 


381c. (utility functions and types for making Typed puScheme primitives 381c)= (S406d) 
unaryOp : (value -> value) -> (value list -> value) 
binaryOp : (value * value -> value) -> (value list -> value) 
arithOp : (int * int -> int) -> (value list -> value) 
arithtype : tyex 


val arithtype = 
FUNTY ([inttype, inttype], inttype) 


As in Chapter 5, the names, values, and types of the primitives are written in one 
long list in chunk (primitive functions for Typed Scheme :: 381d). That list is used to 
build the initial basis. 
381d. (primitive functions for Typed Scheme :: 381d)= (382c) 382a> 
C"+", arithOp op +, arithtype) :: 
c"-", arithOp op -, arithtype) :: 
c™*", arithOp op *, arithtype) :: 
("/", arithOp op div, arithtype) :: 
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The list primitives have polymorphic types. 


382a. (primitive functions for Typed puScheme :: 381d) += (382c) <381d 
C("null?", unaryOp (BOOLV o (fn (NIL ) => true | _ => false)) 
, FORALL ({"'a"], FUNTY ([listtype tvA], booltype))) 
C"cons", binaryOp (fn (a, b) => PAIR (a, b)) 
, FORALL ({"'a"], FUNTY ([tvA, listtype tvA], listtype tvA))) 
C"car", unaryOp (fn (PAIR (car, _)) => car 
| v => raise RuntimeError 
Type systems for ("car applied to non-list " A valueString v)) 
Impcore and juScheme , FORALL (["'a"], FUNTY ([listtype tvA], tvA))) :: 
C"cdr", unaryOp (fn (PAIR (_, cdr)) => cdr 
382 | v => raise RuntimeError 
("cdr applied to non-list " A valueString v)) 
, FORALL (["'a"], FUNTY ([listtype tvA], listtype tvA))) 


Other primitives are relegated to the Supplement. 


Typed uScheme’s basis 


In Typed Scheme, a basis comprises a kind environment, a type environment, 
and a value environment. 

382b. (definition of basis for Typed Scheme 382b)= (S406c) 

type basis = kind env * tyex env * value ref env 

The initial basis starts with the kinds of the primitive type constructors, plus the 
types and values of the primitive functions and values. 

382c. (definition of primBasis for Typed Scheme 382c)= (S406d) 
kinds : kind env 


types : tyex env 
values : value ref env 


val primBasis = 
let fun addKind ((name, kind), kinds) = 
bind (name, kind, kinds) 
val kinds = foldl addKind emptyEnv 
((primitive type constructors for Typed Scheme :: 356) []) 
fun addPrim ((name, prim, funty), (types, values)) = 
( bind (name, funty, types) 
bind (name, ref (PRIMITIVE prim), values) 


primBasis : basis 


val (types, values) = foldl addPrim (emptyEnv, emptyEnv) 
((primitive functions for Typed tScheme :: 381d) []) 
fun addVal ((name, v, ty), (types, values)) = 
( bind (name, ty, types) 
, bind (name, ref v, values) 


val (types, values) = 
foldl addVal (types, values) 
((primitives that aren’t functions, for Typed Scheme :: $407d) []) 
in (kinds, types, values) 
end 
With the primitives in place, the basis is completed by reading and evaluating the 
predefined functions. That code is relegated to the Supplement. 


6.7 TYPE SYSTEMS AS THEY REALLY ARE 


Typed Impcore is a good model of a monomorphic language, but real languages 
are more complicated. As one example, most programming languages, especially 
monomorphic ones, use product types with named fields. These types are often 
called “record” or “struct” types. Their typing rules are mostly straightforward; the 
type of each component is associated with the component’s name, not its position. 

Typed ywScheme is not a good model for any widely used language, because the 
annotations are too heavy: no programmer should have to code the instantiation of 
every use of every polymorphic value. Typed piScheme is, however, a good model 
for an intermediate language to which a real polymorphic source language could 
be translated. It becomes an even better, more powerful model, if type-lambda can 
quantify over a type variable of any kind, not just of kind «. Such quantification is 
permitted in some versions of the functional language Haskell. 

Real type equality is more complicated than what you see in this chapter. Here, 
two types are equal if and only if they apply equal constructors to equal arguments. 
Quantified types are considered equal up to renaming of bound type variables, but 
that is a minor matter. In real languages, type equality is complicated by generativ- 
ity, among other issues. A syntactic form is generative if every appearance creates a 
distinct type, different from any other type. As an example, the product-type con- 
structor in C, called struct, is generative. Standard ML’s sum-type definition form, 
called datatype, is also generative. Languages without generativity are sometimes 
said to compare types using structural equivalence; languages with generativity are 
said to use name equivalence or occurrence equivalence. Generativity is explained in 
detail in Chapter 8. 

The types of names are often more complicated than what you see in this chap- 
ter. In particular, many languages permit a name to be used at more than one 
type, but not at infinitely many types. For example, the + function in ML may be 
used at two types: int * int -> int andreal * real -> real. Such a function 
is not parametrically polymorphic; instead, it is said to be overloaded. The + oper- 
ator in C is even more heavily overloaded; because of implicit type conversions, it 
may be used at many types. In some languages, including Ada, C++, and Haskell, 
programmers can define new overloaded operators or functions. Overloading can 
complicate a type system, but it can also be done simply (Chapter 9). 

Type systems used for research go far beyond what is presented in this book. 
In systems based on dependent types, for example, type checking can be undecid- 
able while still giving useful results in practice! 


6.8 SUMMARY 


Type systems are the world’s most successful formal method. Types guide the con- 
struction of programs: for example, throughout Chapter 2, if you are writing a func- 
tion that consumes a value of type T, most likely the body of your function is the 
elimination form for 7. (And if you are trying to produce a value of type 7’, the 
body of your function might include the introduction form for T’.) Types also pro- 
vide a relatively painless way of documenting code, and they rule out many silly 
programming errors. 

If types are good, polymorphic types are better. Polymorphic types help make 
code reusable, robustly. The polymorphism in Typed Scheme is easy to imple- 
ment, but unpleasant to use—it should be hidden inside a compiler. But similar 
forms of polymorphism can be easy to use, and sometimes a great pleasure. These 
are found in Chapters 7 to 9. 
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A type discipline is usually enforced by a type checker. Most type checkers 
are easy to implement because most type systems have one rule for each syntac- 
tic form. But if you add sophisticated features, parts of a type checker can be- 
come more challenging. In Typed Scheme, these parts include type equivalence, 
which is an interesting aspect of many experimental type systems, and substitu- 
tion, which is a ubiquitous, annoying problem. 


6.8.1 Key words and phrases 


ELIMINATION FORM A syntactic form used to observe a value of a given TYPE. 
For example, the elimination form for a function type is function applica- 
tion. An elimination form “takes information out” that was put in using an 
an INTRODUCTION FORM. The typing rule for an elimination form can be 
called an ELIMINATION RULE. 


FORMATION RULE A rule that says how to make a well-formed type. For example, 
(array int) is a well-formed type. 


GENERATIVITY Ifa language construct always creates a new type distinct from any 
other type, that construct is called generative. Examples of generative con- 
structs include C’s struct and ML’s datatype. 


INSTANTIATION The process of determining at what type a polymorphic value is 
used. In Typed Scheme, a polymorphic value is instantiated explicitly using 
the TYPE-APPLICATION form @. In ML, instantiation is implicit and is handled 
automatically by the language implementation. 


INTRODUCTION FORM A syntactic form used to create a value of a given TYPE. 
For example, the introduction form for a function type is lambda. An in- 
troduction form “puts information in” to the value. The information can be 
recovered using an ELIMINATION FORM. The typing rule for an introduction 
form can be called an INTRODUCTION RULE. 


KIND A means of classifying TYPE CONSTRUCTORS and TYPES. Using kinds makes 
it possible to handle an unbounded number of TYPE CONSTRUCTORS using 
finitely many FORMATION RULES. 


MONOMORPHIC TYPE SYSTEM If every TERM, variable, and function in a language 
has at most one TYPE, that language uses a monomorphic type system. For ex- 
ample, Pascal’s type system is monomorphic. A type system may also be 
POLYMORPHIC. 


MONOTYPE A type that cannot be instantiated. For example, the function type 
int list — int is a monotype. (As contrasted with a POLYTYPE.) 


PARAMETRIC POLYMORPHISM The form of POLYMORPHISM that uses type param- 
eters and INSTANTIATION. 


POLYMORPHIC TYPE SYSTEM Ifa TERM, variable, or function in a language may be 
used at more than one TYPE, that language uses a polymorphic type system. 
For example, ML's type system is polymorphic. A type system may also be 
MONOMORPHIC. 


POLYMORPHISM A language is polymorphic if it is possible to write programs that 
operate on values of more than one type. For example, Scheme and ML are 
polymorphic languages. A value is polymorphic ifit can be used at more than 
one type; for example, the list length function is polymorphic because it can 
operate on many types of lists. 


POLYTYPE Atype that can be instantiated in more than one way. In Typed wScheme, 
a polytype has the form Vay,...,@» .T. (As contrasted with a MONOTYPE.) 


QUANTIFIED TYPE A type formed with the universal quantifier V. Also called a 
POLYTYPE. 


TERM The pointy-headed theory word for “expression.” More generally, a syntactic 
form that is computed with at run time and that may have a TYPE. 


TYPE A specification for a TERM. Or a means of classifying terms. Or a collection 
of values, called the INHABITANTS. 


TYPE ABSTRACTION In PARAMETRIC POLYMORPHISM, the INTRODUCTION FORM 
for a polymorphic type. In Typed wScheme, written type-lambda. 


TYPE APPLICATION In PARAMETRIC POLYMORPHISM, the ELIMINATION FORM for 
a polymorphic type. It substitutes actual type parameters for quantified type 
variables. It is a form of INSTANTIATION. 


TYPE CHECKER A part of a language’s implementation that enforces the rules of 
the TYPE SYSTEM, by checking code before it is run. 


TYPE CONSTRUCTOR The fundamental unit from which TYPES are built. Type con- 
structors come in various KINDS. Nullary type constructors such as int and 
bool are types all by themselves; they have kind *. Other type constructors, 
such as list and array, are applied to types to make more types. 


TYPE SYSTEM A language’s type system encompasses both the set of TYPES that can 
be expressed in the language and the rules that say what TERMS have what 
types. A type system may be MONOMORPHIC or POLYMORPHIC. 


6.8.2 Further reading 


Pierce (2002) has written a wonderful textbook covering many aspects of typed pro- 
gramming languages. Cardelli (1997) presents an alternative view of type systems; 
his tutorial inspired some of the material in this chapter. 

Reynolds (1974) presents the polymorphic, typed lambda calculus now known 
as System F, which is the basis of Typed jsScheme. Reynolds says, 


Although this language is hardly an adequate vehicle for program- 
ming, it seems to pose the essence of the type structure problem, and 
it is simple enough to permit a brief but rigorous exposition of its se- 
mantics. 


I hope you agree. 

Using types to guide the construction of programs is a key part of the “design 
recipe” method of Felleisen et al. (2018). Because the language used by Felleisen 
et al. does not have a static type checker, the types are written only in comments— 
but they are there. Crestani and Sperber (2010) describe an extension in which type 
“signatures” are used to check types at run time. 

Perhaps suprisingly, type systems can be used to guarantee safety even in C pro- 
grams, although at a significant run-time penalty. Systems such as CCured (Necula, 
McPeak, and Weimer 2002) run C programs at about half the speed of unsafe com- 
pilers, but their error-detection power is comparable to that of tools such as Purify 
and Valgrind, which may slow down a program by a factor of 5 to 10. 
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Table 6.5: Synopsis of all the exercises, with most relevant sections 


Exercises Sections Notes 

1to3 6.1 Type-system fundamentals: type errors vs 
run-time errors; introduction forms vs 
elimination forms (§6.3.1); inhabitants of sum 
and product types (§6.4). 

4to7 6.3.1, 6.4 Extending a monomorphic language with lists, 
records, sums, or mutable references. 

8 and9 6.6.3 Coding in a polymorphic language 

10 to 15 6.4, 6.6.2, Extending a polymorphic language with queues, 

6.6.3, 6.6.5 pairs, sums, polymorphic references, or records. 
16and17 6.1.5, 6.6.5, 1.7 Writing typing derivations. 

18and19 6.2, 6.3, 6.6.5 Type checking: add arrays to Typed Impcore’s 
type checker, implement a type checker for 
Typed wScheme. 

20 to 24 6.1, 6.6.5 Metatheory: types are unique, expressions have 
well-formed types, syntactic sugar preserves 
typing, = is an equivalence relation (§6.6.6). 

25and26 6.1.5, 6.5 Metatheory about implementation: type checking 
terminates and prevents bugs. 

27and28 6.6.7 Capture-avoiding substitution: rename variables 
to avoid capture; prove that substitution 
terminates. 

29 to 33 6.1.5, 6.6.5, 6.6.7. Holes in type systems: what goes wrong when 


6.9 EXERCISES 


restrictions are lifted. 


The exercises are summarized in Table 6.5. This chapter’s exercises are unusually 
diverse; they include programming, adding new typing rules, proving things about 
type systems, extending interpreters, and subverting type systems. They include 
these favorites: 


* Nothing solidifies your understanding of type systems like writing a type 
checker. You should write one for Typed Scheme, using the typing rules 
as your specification (Exercise 19; use Figures 6.9 to 6.12, which appear 
on pages 394 to 396). If you want your type checker to be sound, you will 
also want to complete the implementation of capture-avoiding substitution 
(Exercise 28). An easier alternative, or a warmup, would be to extend the 
type checker for Typed Impcore so it supports arrays (Exercise 18; use Fig- 
ures 6.6 to 6.8, which appear on pages 391 and 392). 


+ Another way to develop understanding is to write typing rules for familiar 
language constructs (Exercises 4 to 7). The easiest and more familiar con- 
structs are for lists (Exercise 4). 


* To understand both the power and the agony of programming with explicit 
polymorphism, implement exists? or all? in Typed zScheme (Exercise 9). 


* To understand how explicit polymorphism benefits implementors and lan- 
guage designers, extend Typed wScheme with new type constructors (Exer- 
cises 10 to 13). You won't have to change any infrastructure. The easiest, most 
familiar new type constructor is the pair type constructor (Exercise 11). 


* Type systems lend themselves well to metatheory. My favorite metatheoretic 
exercise is to show that in Typed Scheme, any type that classifies a term is 
well formed and has kind * (Exercise 23). Exercise 20 calls for similar rea- 
soning but has a more familiar conclusion: type checking is deterministic. 


6.9.1 Retrieval practice and other short questions 


A. 


What’s an example of a checked run-time error in Impcore that is guaranteed 
to be prevented by the type system of Typed Impcore? 


What's an example of a checked run-time error in Impcore that is not guaran- 
teed to be prevented by the type system of Typed Impcore? 


How many values inhabit the type bool? 
How many terms have type bool? 


In Typed Impcore, a global variable may have an array type. How many distinct 
array types are possible? 


When you look up a name x in environment I'¢, what information about x do 
you get back? 


How do you pronounce the judgment form lg, 5, F e: 7? 
How do you pronounce the judgment form A, IF e: rT? 


When the Typed Impcore interpreter checks the type of a WHILE loop, is the 
type checking guaranteed to terminate? Why or why not? 


When the Typed Impcore interpreter checks the type of a WHILE loop, how 
does the type of the loop’s body affect the type of the loop? 


If the body of a WHILE loop doesn’t have a type, what happens? 


In Typed Impcore, what syntactic form is the introduction form for array types? 


. In Typed Scheme, what syntactic form is the introduction form for function 


types? 

In Typed jsScheme, what syntactic form is the elimination form for function 
types? 

In Typed Scheme, what syntactic form is the introduction form for polymor- 
phic types? 

In Typed pScheme, what syntactic form is the elimination form for polymor- 
phic types? 

In Typed jsScheme, what is the type of the primitive function “nu11?”? 

In Typed puScheme, the primitive function cons does not have a function type— 
it has a polymorphic type. How do you get it to act as a function? 

In both Typed Impcore and Typed Scheme, what types have to be checked to 
make sure they are well formed? Where would an ill-formed type come from? 
In Typed pScheme, why aren’t there type-formation rules for list types? How 
does the type checker know if a list type is well formed? 

In Typed juScheme, what's the relationship between instantiation and substitu- 
tion? 


Why does Typed wScheme need a complicated = relation? Why doesn’t Typed 
Impcore need such a thing? 
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6.9.2 Type-system fundamentals 


1. 


3. 


Differences between type errors and run-time errors. Programming-language 
people get good at thinking about phases of computation. A type-checking 
phase, which happens before the evaluation phase, is introduced in this 
chapter. And in different phases, different things can go wrong; a type 
error is not the same as a run-time error. To convince yourself that you 
understand what can go wrong in each phase, create unit tests using both 
check-type-error and check-error. 


(a) Using the array-at primitive, create one test for each phase. 


(b) Using an integer-arithmetic primitive, create one test for each phase. 
All four tests should pass. 


Introduction forms and elimination forms. In this exercise, you identify syn- 
tactic forms (and their associated rules) as introduction forms or elimina- 
tion forms. The exercise is modeled on communication techniques found in 
languages like PML/Pegasus, Concurrent ML, and Haskell. 


A expression of type PROTO(T) is a set of instructions, or protocol, for com- 
municating with a remote server. Such an expression can be run by a special 
syntactic form, which communicates with the server. When a communica- 
tion is run, the local interpreter gets an outcome of type 7. Here is a grammar, 
with informal explanations: 


exp ::= send exp Send a value to the server 
| receive Receive a value from the server 
| dox<¢ exp, inexp, Protocol exp,, whose outcome is z, 
followed by exp, 
| locally exp Produce result exp locally, without 
communicating 
| run exp Run a protocol 


An exp is given a type by these rules: 


PROTO SEND 
Tis atype Tre:7 
d 
PROTO(T) is a type TF send e : PROTO(UNIT) 
Do 
RECEIVE IF e; : PROTO(T) 
Tisatype T,x2:7b eg: PROTO(T’) 
d 
TF receive : PROTO(T) [+ do x + e; in eg : PROTO(T’) 
LOCALLY RUN 
Tke:7t IF e: pRoto(rT) 
TF locally e : PROTO(T) [TFrune:7 


Classify each rule as a formation rule, an introduction rule, or an elimination 
rule. Justify your answers. 


Counting inhabitants. Type bool is inhabited by the two values #t and #f. 
Let’s say type lettergrade is inhabited by values A, B, C, D, and F’. 

(a) List all the values inhabited by product type bool x lettergrade. 

(b) List all the values inhabited by sum type bool + lettergrade. 


(c) Are your results consistent with the words “sum” and “product”? Justify 
your answer. 


6.9.3 Extending a monomorphic language 


4. Rules for lists in Typed Impcore. In this exercise, you add lists to Typed Imp- 
core. Use the same technique we use for arrays: devise new abstract syn- 
tax to support lists, and write appropriate type-formation, type-introduction, 
and type-elimination rules. The rules should resemble the rules shown in 


Section 6.4. 

Review the discussion of rules in the sidebar on page 347, and make it obvi- $6.9 
ous which rules are formation rules, which rules are introduction rules, and Exercises 
which rules are elimination rules: Divide your rules into three groups and 

label each group. 389 


* Some rules can be classified just by looking to see where list types 
appear. For example, a rule for null? should have a list type in the 
premise but not in the conclusion, so nu11? has to be an elimination 
form. Similarly, a car rule should have a list type in the premise but not 
necessarily in the conclusion, so it too has to be an elimination form. 


Other rules have list types in both premises and conclusion. When you 
have forms like cons and cdr, which both take and produce lists, you 
have to fall back on thinking about information. Does a form put new 
information into a value, which can later be extracted by another form? 
Then it is an introduction form. Does a form put in no new informa- 
tion, but only extract information that is already present? Then it is an 
elimination form. 


Your abstract syntax should cover all the list primitives defined in Chapter 2: 
the empty list, test to see if a list is empty, cons, car, and cdr. Your abstract 
syntax may differ from the abstract syntax used in jsScheme. 


Be sure your rules are deterministic: it should be possible to compute the 
type of an expression given only the syntax of the expression and the current 
type environment. 


5. Rules for records in Typed Impcore. Following the same directions as in Exer- 
cise 4, give typing rules for records with named fields. 


6. Rules for sums in Typed Impcore. Following the same directions as in Exer- 
cise 4, give typing rules for sums with named variants. 


7. Rules for mutable references in Typed Impcore. Mutable cells can be represented 
by a type constructor ref. The appropriate operations are ref, !, and :=. 
The function ref is like the function allocate in Chapter 2; applying ref to 
avalue v allocates a new mutable cell and initializes it to hold v. Applying ! to 
a mutable cell returns the value contained in that cell. Applying := to a mu- 
table cell and a value replaces the contents of the cell with the value. (These 
functions are also part of Standard ML.) 


Give typing rules for a type constructor for mutable cells. (See also Exer- 
cise 13.) 


6.9.4 Coding in a polymorphic language 
8. Folds. Implement fold1 and foldr in Typed puScheme. 


(a) Both functions should have the same polymorphic type. Give it. 


(b) Write an implementation of each function. 
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10. 


11. 


12. 


Higher-order, polymorphic linear search. Implement exists? and all? in 
Typed wScheme. 

(a) Both functions should have the same polymorphic type. Give it. 

(b) Write an implementation of exists? using recursion. 


(c) Write an implementation of al1? using your implementation of exists? 
and De Morgan’s laws. 


6.9.5 Extending a polymorphic language 


Add queues to Typed Scheme. A great advantage of a polymorphic type sys- 
tem is that a language can be extended without touching the abstract syntax, 
the values, the type checker, or the evaluator. Without changing any of these 
parts of Typed psScheme, extend Typed psScheme with a queue type construc- 
tor and the polymorphic values empty-queue, empty?, put, get-first, and 
get-rest. (A more typical functional queue provides a single get opera- 
tion which returns a pair containing both the first element in the queue and 
any remaining elements. By instead providing get-first and get-rest, you 
avoid fooling with pair types.) 


(a) What is the kind of the type constructor queue? Add it to the initial A. 


(b) What are the types of empty-queue, empty?, get-first, get-rest, 
and put? 


(c) Add the new primitive functions to the initial [ and p. You will need to 
write implementations in Standard ML. 


Add pairs to Typed Scheme. Without changing the abstract syntax, values, 
type checker, or evaluator of Typed Scheme, extend Typed Scheme with 
the pair type constructor and the polymorphic functions pair, fst, and snd. 


(a) What is the kind of the type constructor pair? Add it to the initial A. 
(b) What are the types of pair, fst, and snd? 


(c) Add the new primitive functions to the initial I’ and p. As you add them 
to p, you can use the same implementations that we use for cons, car, 
and cdr. 


Add sums to Typed jsScheme. Without changing the abstract syntax, values, 
type checker, or evaluator of Typed jsScheme, extend Typed pScheme with 
the sum type constructor and the polymorphic functions left, right, and 
either. 


(a) What is the kind of the type constructor sum? Add it to the initial A. 


(b) What are the types of left, right, and either? 


(c) Page 349 gives algebraic laws for pair primitives in a monomorphic lan- 
guage. If the sum primitives were added to a monomorphic language, 
what would be the laws relating LEFT, RIGHT, and EITHER? 


(d) Since left, right, and either have the polymorphic types in part 12(b), 
what are the laws relating them? 


(e) Add left, right, and either to the initial [ and p of Typed pScheme. 
Try representing a value of sum type as a PAIR containing a tag anda 
value. 
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Figure 6.6: Type-formation rules for Typed Impcore 


LITERAL 


Te,0¢,P,e:7 


Te, P,P, - LITERAL(v) : INT 


FORMALVAR GLOBALVAR 
x € dom, x<¢doml, «x€domIls 

Te, T¢,P, + var(z) : T(z) Te, Pg, - var(x) : Te(x) 
FORMALASSIGN GLOBALASSIGN 
xé€doml, I,(4)=7 x«¢édomT, «edomlg Te(x)=7 

Peel gr esr Ve,0g,0,-e:7 
Te, 0 g,0, F SET(x,e) : 7 Te, 0,0, + set(a2,e) : 7 

IF 


Te, 0¢,P, F e1 : BOOL Te,0¢,0) eg: 7 Te, 0,0, e3:7 
Te, 0g, Pp + 1F(e1, €2, €3) 2 T 


WHILE 
Te, 0¢,P, F e1 : BOOL (ze, Ve, pi €27 


Te, 0y,P,  WHILE(€}, €2) : UNIT 


BEGIN 
Te, 0¢,P, e1: 7% tee Te,0¢,0 pF en: Tr 


Regt BEGIN Cigsdext a) eH 


EMPTYBEGIN 


Te, 0y,P, / BEGIN() : UNIT 


APPLY 
Tg(f) =m X +++ X OT Te,0g,Pp-e:n, Leicn 


Te, Tg, - APPLY(f,€1,.--,€n) 27 


EQ PRINTLN 
Te,0¢,0,F e1: 7 Te, 0¢,P,F e2:7 Te,0¢,P,F e:7 


Te, T¢,T, - EQ(e1, €2) : BOOL Te, Tg, + PRINTLN(e) : UNIT 


Figure 6.7: Typing rules for Typed Impcore expressions 
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Figure 6.8: Typing rules for Typed Impcore definitions 


13. Add references to Typed Scheme. In Typed Scheme, it is not necessary to add 
any special abstract syntax to support mutable cells as in Exercise 7. Give the 
kind of the ref constructor and the types of the operations ref, !, and :=. 


14. Add simple polymorphic records to Typed Scheme. Extend Typed jsScheme by 
adding polymorphic records with named fields. Types of fields are not speci- 
fied; instead, the extension creates functions that work like the record func- 
tions in Chapter 2, except these functions are polymorphic. 


(a) Add a new form of definition. It should have this concrete syntax: 
def ::= (record record-name ( { field-name} )) 
The abstract syntax can be this: 
RECORD of name * name list 


(b) Modify typdef so that it returns a new kind environment A’ as well as 
a new type environment I”. 


(c) A record definition should extend A by adding a new type constructor 
record-name with kind *, x --- X *, => *, where n is the number of 
field-names. 


(d) The record definition should add a new function make-record-name. 
This function should take one argument for each field and build a 
record value. 


(e) For each field, the record definition should add a function named by 
joining the record-name and field-name with a dash. This function should 
extract the named field from the structure and return its value. 


As an example, I define an assoc record with fields key and value: 


398a. (exercise transcript 393a) = 393b > 
-> (record assoc key value) 
-> (val p ((@ make-assoc sym int) 'class 152)) 
p : (assoc sym int) 
-> ((@ assoc-key sym int) p) 
class : sym 
-> ((@ assoc-value sym int) p) 
152 : int $6.9 
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15. Add more expressive records to Typed Scheme. Extend Typed wScheme by 
adding records with fields that are named and typed. This extension cre- 
ates record functions whose types are determined by the types in the record 
specification. 
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(a) Add a new kind of definition. It should have this concrete syntax: 
def ::= (typed-record (record-name { ' type-variable-name } ) 
c{ [field-name : type] }) ) 
This sort of record is also polymorphic, but under more control: type 
parameters are listed explicitly, and the type of each field is declared. 
The abstract syntax can be this: 


TYPED_RECORD of name * name list * (name * tyex) list 


(b) Modify typdef so that it returns a new kind environment A’ as well as 
a new type environment I’. 


(c) The typed-record definition should extend A by adding a new type 
constructor record-name with kind *; x --- X *, => *, where n is the 
number of type-variable-names in the definition. 


(d) The typed-record definition should add a new function make-record- 
name. This function should take one argument for each field and build 
a record value. 


(e) For each field, the typed-record definition should add a function 
named by joining the record-name and field-name with a dash. This func- 
tion should extract the named field from the structure and return its 
value. 


Here is an example. 


393b. (exercise transcript 393a) += <1393a 
-> (typed-record (assoc 'a) ([key : sym] [value : 'a])) 
-> (val p ((@ make-assoc int) 'class 152)) 
p : (assoc int) 
-> ((@ assoc-key int) p) 
class : sym 
-> ((@ assoc-value int) p) 
152 : int 
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Figure 6.9: Kind-formation rules for Typed Scheme 
Type systems for KINDINTROCON KINDINTROVAR 
Impcore and juScheme rR ue domA aédomA 
erie 
394 A TYCON(jt) :: A(s) AF TyvaR(qa) :: A(a) 
KINDAPP 
ATi ky XX Kn SK AFR: k, L<i<n 
AF CONAPP(T, [71,---5T7n]) 2 & 
KINDFUNCTION KINDALL 
AFR: * l<i<n Akt: FANG Kos ese: seem Preeree  al mele e 
AF TX ++ X TT AF FORALL((Q1,..-,@n),T) 1 * 


Figure 6.10: Kinding rules for Typed Scheme types 


6.9.6 Typing derivations 
16. The type of a polymorphic function in Typed puScheme. 


(a) What is the type of the following function? 


(type-lambda ('a) (type-lambda ('b) 
(lambda ([f : ('a -> 'b)] [x : 'a]) (f x)))) 
(b) Using the typing rules from the chapter, give a derivation tree proving 
the correctness of your answer to part (a). 


17. The type of a polymorphic function in extended Typed jsScheme. Suppose we get 
tired of writing @ signs everywhere, so we extend Typed ppScheme by making 
PAIR, FST, and SND abstract syntax instead of functions. 


(a) What is the type of the following function? 
(type-lambda ('a) (type-lambda ('b) 
(lambda ([p : (pair 'a 'b)]) (pair (snd p) (fst p))))) 


(b) Using the typing rules from the chapter, give a derivation tree proving 
the correctness of your answer to part (a). 


6.9.7 Implementing type checking 


18. Type checking for arrays. Finish the type checker for Typed Impcore so that it 
handles arrays. It is sufficient to implement the four cases in code chunk 348. 


19. Type checking for Typed Scheme. Write a type checker for Typed wScheme. 
That is, implement typdef in code chunk 366. Although you could write this 
checker by cloning and modifying the type checker for Typed Impcore, you 


VAR 
xé€domT T[(#)=7 


A,TF var(a) : 7 


A,Tre:r 


SET WHILE 
A,TFe:7r «€doml Per A,TF e; : bool A,TF e.:7 
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IF 395 
A,TF e; : bool A,TF eg:T A,TF eg: 7 


A, TF 1F(e1, €2, €3) : T 


BEGIN _ . 
A,Tre: 7, 1<i<n rene 


A,TF BEGIN(e1,...,€n) : Tn A,T' BEGIN() : unit 


LET 
A,Tke:7, 1<i<n A, Tf{a1 9 1,..-,2n > mph e:t 
A, TF Let ((a1,€1,---,2n,€n),€) 2 T 


LETSTAR 
A, TF LET ((x1, €1), LETSTAR( (9, €2,---;%n,€n),€)):T n>O 
A,TF LETSTAR((@1, €1,---,2n,@n),€) 2 T 


EMPTYLETSTAR 


A,TrFe:r 
A, LETSTAR((),e) : 7 


LETREC 
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A, TF LETREC((21 : 71, €1,---;2n : Tn; €n), €) 2 T 


LAMBDA 
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A,TF ApPLy(e, €1,...,€n) 2 T 
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>) 


A, TF TYLAMBDA(Q1,...,Q@n,€) : VQ1,.--,Qn -T 
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A,TFe:Vay,...,Qn.T AFju*, l<i<n 


* 
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Figure 6.11: Typing rules for Typed Scheme expressions 


VAL 


R ; A,TRe:7 
Carn aa (vat(a,e),A,T) > Piao 7} 
VALREC 
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Type systems for e has the form LAMBDA(-- -) (vAL(it,e), A,T) >I” 
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(DEFINE(f,7, (@1:71,---;%n : T),e), A, T) 3 I” 


Figure 6.12: Typing rules for Typed Scheme definitions 


will get better results if you build a checker from scratch by following the typ- 
ing rules for Typed Scheme, which are shown in Figure 6.11 on the previous 
page and in Figure 6.12 above. 


* When a type in a program is supposed to be the type of a variable, the 
rules require that type to have kind *. You will find such types in the 
syntax of a define, val-rec, and lambda. The requirement that such 
types have kind * can be enforced by the function asType on page 380. 


When you typecheck literals, use the rules on page 363. Although these 
rules are incomplete, they should suffice for anything the parser can 
produce. Ifa literal PRIMITIVE or CLOSURE reaches your type checker, 
the impossible has happened, and your code should raise an appropri- 
ate exception. 


6.9.8 Metatheory 


20. Types are unique. Prove that an expression in Typed Impcore has at most one 
type. That is, prove that given environments I’, I'y, I’, and abstract-syntax 
tree e, there is at most one 7 such that Ie, gy, , F e: T. 


21. Desugaring preserves types. The sidebar on page 362 notes that the only defi- 
nition form we really need is val; define and val-rec can be expressed as 
syntactic sugar. The desugaring of define is given in the text; in this exer- 
cise, you desugar val-rec. 


(a) Express VAL-REC as syntactic sugar. That is, specify a translation from 
an arbitrary VAL-REC form into a combination of VAL and LETREC 
forms. 


(b) Prove that your translation preserves typing. That is, prove that a VAL- 
REC form is well typed if and only if its desugaring is well typed. And 
prove that when both are well typed, the final type environments on the 
right-hand side of the — judgment are equal. 


22. The type of a Typed Impcore expression is well formed. Using a metatheoretic 
argument about typing derivations in Typed Impcore, prove that if there is a 
derivation of a typing judgment Ie, Ty, T°, F e : 7, there is also a derivation 


23. 


24. 


of the judgment “7 is a type.” Use structural induction on the derivation of 
the typing judgment. 


The type of a Typed Scheme expression is well formed. In Typed jsScheme, types 
like list and pair are well formed, with kinds * > * and * x * — *, respec- 
tively, but they are not the types of any term: no expression can have type 
list or pair. The type of a term must have kind *. Using a metatheoretic 
argument about typing derivations in Typed jzScheme, prove that if there is 
a derivation of a typing judgment A,I' e : 7, there is also a derivation of 
the judgment A | 7 :: x. Use structural induction on the derivation of the 
typing judgment. 


“Type equivalence” is an equivalence. Prove that =, as defined in Section 6.6.6 
(page 367), is an equivalence relation: 

(a) For any T,T =T. 

(b) For any 7 and 7’, iff = 7’, then 7’ =r. 

(c) For any 71, 72, and 73, if 7, = T2 and T2 = 73, then 7, = 73. 


In each case, structure your proof by assuming you have a derivation of the 
fact or facts assumed, and construct a derivation of the conclusion. 


6.9.9 Metatheory about implementation 


25. 


26. 


Type checking terminates. Using an argument about the rules in the type sys- 
tem, prove that type checking for Typed Impcore always terminates. 


Type checking is sound. Show that if an expression in Typed Impcore has a 
type, and if the values stored in the value environments €, ¢, and p inhabit 
the types in the corresponding type environments, then the eval function 
never raises the exception BugInTypeChecking. 


6.9.10 Capture-avoiding substitution 


27. 


28. 


Proof that substitution terminates. Function tysubst on page 374 works by 
defining and calling an inner recursive function subst, with which tysubst 
is mutually recursive. We need to know that no matter what Typed uScheme 
code a programmer writes, tysubst and subst terminate. Of particular con- 
cern is the recursive call in chunk 375b: given a FORALL type, the code makes 
a recursive call on a similar FORALL type. Could this process repeat forever? 


Prove that tysubst terminates by showing that at every recursive call some- 
thing is getting smaller. You might consider assigning each type a pair of 
numbers and show that the pair shrinks lexicographically. One number 
worth considering is the number of bound type variables that are in the range 
of the substitution. 


Renaming type variables. In substitution, rename type variables to avoid cap- 
ture: Given a type Va),...,Q@, . T and a set C’ of captured type variables, 
rename as many a;’s as necessary to avoid conflicts with variables in C and 
with free variables of Tr. Do so in the body of function renameForallAvoiding, 
which is nested within function tysubst on page 374: 


397. (definition of renameForallAvoiding for Typed Scheme [prototype] 397)= 


renameForallAvoiding : name list * tyex * name set -> tyex 


fun renameForallAvoiding (alphas, tau, captured) = 
raise LeftAsExercise "renameForallAvoiding" 
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Calling renameForallAvoiding((a1,...,@,],7,C) must choose variables (3; 
not in Cand return a type V(1,..., Gn . 7’ with these properties: 
VB1,..-,Bn.T =Va1,...,Qn-T; 


{61,---,Bn} ANC =90. 


For each q;, there are two cases: 


* Ifa; ¢ C, then it doesn’t need to be renamed, and to maximize read- 
ability of the resulting type, let 8; = a,. 


* Ifa; € C, then 6; must be a new variable that does not appear in C, is 
not free in 7, and is different from every a. 


To find a §;, use function freshName, which returns a name based on a@ but 
not in a given set of type variables. 
398. (shared utility functions on sets of type variables 398) = ($405a) 


freshName : name * name set -> name 


fun freshName (alpha, avoid) = 
let val basename = stripNumericSuffix alpha 
val candidates = 


streamMap (fn n => basename A "-" A intString n) naturals 
fun ok beta = not (member beta avoid) 
in case streamGet (streamFilter ok candidates) 
of SOME (beta, _) => beta 
| NONE => raise InternalError "ran out of natural numbers" 
end 


6.9.11 Loopholes in type systems 


29. 


30. 


Changing a thing’s type can break the type system. Ifa global variable or function 
is already defined, Typed Impcore doesn’t let you write a new definition at a 
different type. To show why such definitions aren't permitted, complete this 
exercise: 


(a) Remove the restriction that a val binding may not change the type of 
the value bound. (An easy way to do this is to change the condition in 
chunk 341c so that it says “if true.”) 


(b) With the restriction removed, create a Typed Impcore program whose 
evaluation raises BugInTypeChecking, e.g., by adding 1 to an array. 


(c) Restore the restriction on val, and remove the restriction that a define 
binding may not change the type of a function. 


(d) With the restriction removed, create a Typed Impcore program whose 
evaluation raises BugInTypeChecking, e.g., by doing an array lookup 
on an integer. 


Polymorphic mutable reference cells are unsound. In a polymorphic system, the 
ref constructor (Exercise 13) leads to unsoundness: it can be used to subvert 
the type system. You can wrap ref in a type-lambda in a way that allows 
you instantiate a polymorphic, mutable data structure at any type you want. 
You can then instantiate it at one type with := and at another type with !, 
enabling you to write a function that, for example, converts a Boolean to an 
integer. 


(a) Using polymorphism and references, trigger the BugInTypeChecking 
exception in Typed Scheme by adding 1 to #t. 


(b) Write an identity function of type bool — int 
(c) Write a polymorphic function of type Va, 3 .a— £. 


(d) Close this dreadful loophole in the system by making ref abstract syn- 
tax and permitting it to be instantiated only at a type that has no free 
type variables. 


31. A type-lambda may not abstract over a variable in the environment. In Typed 
pScheme, remove the restriction that a type-lambda may not abstract over 
a type variable that’s free in the type environment. Now 


(a) Write the const function of type Va.a—> V8.8 >a. 


(b) Write a similar function unsafe-const that uses a in both places, in- 
stead of the two distinct a and 3. (Change the inner ( to an a.) 


(c) Use unsafe-const to define a variable that has type int but value #t. 


(d) Trigger BugInTypeChecking by adding one to this variable. 


32. Misuse of type-lambda can give any term any type. The discussion of Typed 
pScheme rule TYLAMBDA on page 365 observes that if the side conditions 
are not enforced, then 


{a :: *}, {a@: a} TYLAMBDA(a, x): Va.a. 


This observation suggests that by wrapping TYLAMBDA(q, x) in code that in- 
troduces both a and @ into the kind environment and ~ into the type envi- 
ronment, then instantiating TYLAMBDA(q, x) at 3, one might well be able to 
define a function of type Va, 8.a— f. 


(a) Define such a function. Call it cast, or perhaps Obj.magic. 


(b) To enable cast to be accepted by the interpreter, remove the restriction 
that a type-lambda may not abstract over a type variable that’s free in 
the type environment. 


(c) Use cast to trigger BugInTypeChecking. 


33. Variable capture can break the type system. In Typed sScheme, change the code 
in chunk 375b so that substitution is always done naively, in a way that al- 
lows the capture of a V-bound variable. (It suffices to write if true instead 
of if null actual_captures.) 


(a) Define a typed, polymorphic version of function flip-apply from 
page 376, which should have type V3.8 — (Va. (8 4 a) > a). 


(b) Using type-lambda and suitable instantiations of flip-apply, define 
a function cast that behaves like the identity function but has type 
Va,8.a— £. This function is not acceptable; in a correct version 
of Typed Scheme, it doesn’t typecheck. But if you allow variable cap- 
ture, you can write it. 


(c) Use cast to introduce a variable that has type int but value #t. 


(d) Trigger BugInTypeChecking by adding one to this variable. 
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ML and type inference 


It soon appeared intolerable to 

have to declare—for example— 

a new maplist function for mapping a function over a 
list, every time a new type of list is to be treated. Even 
if the maplist function could possess what Strachey 
called “parametric polymorphism,” it also appeared 
intolerable to have to supply an appropriate type 
explicitly as a parameter, for each use of this function. 


Robin Milner, How ML Evolved 


Typed Impcore and Typed jsScheme represent two extremes. Typed Impcore is 
easy to program in and easy to write a type checker for, but because it is monomor- 
phic, it cannot accept polymorphic functions, and it can accommodate new type 
constructors and polymorphic operations only if its syntax and type checker are 
extended. Typed Scheme is also easy to write a type checker for, and as a poly- 
morphic language, it can accept polymorphic functions, and it can accommodate 
new type constructors and polymorphic functions with no change to its syntax or 
its type checker. But Typed jsScheme is difficult to program in: as Milner observed, 
supplying a type parameter at every use of every polymorphic value soon becomes 
intolerable. To combine the expressive power of polymorphism with great ease of 
programming, this chapter presents a third point in the design space: nano-ML. 
Nano-ML is expressive, easy to extend, and also easy to program in. This ease of 
use is delivered by a new typing algorithm: instead of type checking, nano-ML uses 
type inference. 

A language with type inference doesn't require explicit type annotations; the 
types of variables and parameters are discovered by an algorithm. Type inference 
is used in such languages as Haskell, Miranda, OCaml, Standard ML, and Type- 
Script. Type inference works with a limited form of polymorphism: typically the 
Hindley-Milner type system. In this type system, a quantified V type may appear only 
at top level; a V type may not be passed to a type constructor. In particular, a V type 
may not appear as an argument in a function type. This restriction makes type 
inference decidable. 

In this chapter, the Hindley-Milner type system and its type inference are illus- 
trated by nano-ML, a language that is closely related to Typed wScheme. 


* Like Typed Scheme, nano-ML has first-class, higher-order functions, and 
its values are S-expressions. 


* Like Typed zScheme, nano-ML has polymorphic types that are checked at 
compile time. 
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* Unlike Typed wScheme, nano-ML has implicit types. In nano-ML, the pro- 
grammer never writes a type or a type constructor. 


Unlike Typed jsScheme, nano-ML has no mutation. Nano-ML lacks set, and 
its names stand for values, not for mutable locations. Because there is no 
mutation, nano-ML programs are nearly always written in applicative style. 
Imperative actions are limited to printing and error primitives. 


* Unlike Typed Scheme, nano-ML restricts polymorphism: quantified types 
may appear only at top level. This restriction enables nano-ML to instantiate 
polymorphic values automatically and also to introduce polymorphic types 
automatically. Explicit @ and type-lambda are not needed. 


Nano-ML, Typed Scheme, and jsScheme are closely related. If the types are 
erased from a Typed psScheme program, the result is a valid uScheme program. 
And if the program does not use set or while, and if it uses type-lambda appropri- 
ately, it is also a valid nano-ML program. 

Like the interpreter for Typed zScheme, nano-ML’s interpreter is based on the 
pScheme interpreter from Chapter 5. And as with the type checker from Chapter 6, 
substantial parts of the implementation are left as exercises. 


7.1 NANO-ML: A NEARLY APPLICATIVE LANGUAGE 


Aside from its type system, nano-ML differs from pScheme by forbidding mu- 
tation.’ Mutation is the archetypal example of an imperative feature. Although 
nano-ML does not have mutation, it does have other imperative features: printing 
primitives, error, and begin (see sidebar). 

Nano-ML and psScheme have subtly different definition forms. In puScheme, a 
val definition can mutate an existing binding, but in nano-ML, val always creates 
a new binding. To define a recursive function, nano-ML uses a val-rec defini- 
tion form like Typed jsScheme’s val-rec. And like Typed wScheme, nano-ML uses 
define as syntactic sugar for a combination of val-rec and lambda. 

Nano-ML needs fewer primitives than jsScheme. Because nano-ML has a type 
system, every symbol, number, Boolean, and function is identified as such at com- 
pile time—so nano-ML doesn’t need type predicates symbo1?, number?, boolean?, 
or function?. Nano-ML does need the nu11? predicate, which is used to tell the 
difference between empty and nonempty lists, but it does not also need pair?. 

Except for the addition of val-rec, the concrete syntax of nano-ML, which 
is shown in Figure 7.1 on page 404, is mostly a subset of that of uScheme. But 
nano-ML’s syntax also includes forms for type-related unit tests: check-type, 
check-type-error, and check-principal-type. 

The check-type test serves the same role as the corresponding test in Typed 
LScheme, but as explained in Section 7.4.6, it is more permissive. To test for type 
equivalence in nano-ML, use check-principal-type. 

402. (transcript 402) = 409b > 
-> (check-principal-type revapp 
(forall ['a] ((list 'a) (list 'a) -> (list 'a)))) 
-> (define revapp (xs ys) 
(if (null? xs) 
ys 
(revapp (cdr xs) (cons (car xs) ys)))) 


Function revapp is written exactly as we wrote it in zScheme. 


1To add mutation soundly requires some subtlety in the type system, and in this chapter we are going 
for simplicity. Mutation is relegated to Exercise 23. 


Imperative features 


Despite the fact the Impcore is a procedural language and the dialects of 
pScheme are functional languages, all three share syntactic forms devoted to 
imperative features: set, while, and begin. These forms are used more heavily 
in procedural languages; functional languages emphasize let binding, function 
application, and recursion. In nano-ML, imperative features are so little empha- 
sized that set and while are entirely absent, and begin is used rarely—primarily 
for printf-style debugging. 

What are imperative features, and why do we care? A feature is imperative if 
when the feature is used, different orders of evaluation can produce different results.* 


* The set form, also called assignment or mutation, is an imperative fea- 
ture: if two expressions assign to the same mutable location, the order of 
evaluation matters. In particular, after two assignments, the second as- 
signment determines what value the location holds. 


+ Input and output are imperative features. For example, if different print 
expressions are evaluated in different orders, the program’s output is dif- 
ferent. Similarly, ifa program reads x and y from its input, it may produce 
different results depending on the order in which the variables are read. 


+ Exceptions are an imperative feature: if different expressions raise dif- 
ferent exceptions, order matters. Which exception is raised depends on 
which expression is evaluated first. In sScheme and nano-ML, error is 
a similar imperative feature, because the error message depends on the 
order of evaluation. 


In the presence of imperative features, order of evaluation is controlled by se- 
quencing and looping constructs, like begin and while. 


* Sequencing is fundamental to procedural programming. In languages 
such as C, C++, and OCaml, which have imperative features but do not say 
in what order a function’s arguments are evaluated, sequencing is essen- 
tial; without it, some programs’ behavior would be impossible to predict. 


* Loops are useful only in the presence of imperative features. Without im- 
perative features, for example, a while expression has only uninteresting 
outcomes: nontermination, immediate termination, or a run-time error. 


Limiting imperative features, as in nano-ML, has two benefits: 


* When imperative features are absent, we can reason about programs 
more easily, especially using algebraic laws. We can more easily build 
correct programs, and we can more easily transform programs to make 
them more efficient. 


* When imperative features are absent or restricted, a compiler can often 
produce better code. In ML-like languages, restrictions on mutation have 
been used to reduce memory requirements, improve instruction schedul- 
ing, and reduce the overhead of garbage collection. 


A language containing no imperative features may be called pure; a language 
containing imperative features may be called impure. 


*For purposes of deciding whether a feature is imperative, we don’t consider nontermination to 
bea “different result.” (A reordering that makes a program terminate more often is typically benign.) 


§7.1 
Nano-ML: A 
nearly applicative 
language 
403 
car P 440a 
cdr P 440a 
cons P 440a 


null? P 440a 


ML and type 
inference 


404 


def = (val variable-name exp) 


unit-test 


exp 


let-keyword :: 
type-exp 


formals 
literal 
S-exp 


numeral 


*name 


(val-rec variable-name exp) 

exp 

(define function-name (formals) exp) 
(use file-name) 

unit-test 


(check-expect exp exp) 
(check-assert exp) 

(check-error exp) 

(check-type exp type-exp) 
(check-principal-type exp type-exp) 
(check-type-error exp) 


literal 

variable-name 

(if exp exp exp) 

(begin {exp}) 

(exp { exp} ) 

(let-keyword c{ (variable-name exp) }) exp) 
(lambda (formals) exp) 


let | let* | letrec 


type-constructor-name 

' type-variable-name 

(forall [{ ’ type-variable-name } ] type-exp) 

({ type-exp -> type-exp) 

(type-exp { type-exp} ) 

{ variable-name} 

numeral | #t | #f | "S-exp | (quote S-exp) 

literal | symbol-name | ({S-exp}) 

token composed only of digits, possibly prefixed with a plus 
or minus sign 


token that is not a bracket, a numeral, or one of the “re- 
served” words shown in typewriter font 


Figure 7.1: The concrete syntax of nano-ML 


7.2 ABSTRACT SYNTAX AND VALUES OF NANO-ML 


Nano-ML’s abstract syntax is the same as psScheme’s, minus WHILEX and SET. 


404. (definitions of exp and value for nano-ML 404)= (S419b) 


datatype exp 


and let_flavor 
and (definition of value for nano-ML 405b) 


LITERAL of value 

VAR of name 

IFX of exp * exp * exp 

BEGIN of exp list 

APPLY of exp * exp list 

LETX of let_flavor * (name * exp) list * exp 
LAMBDA of name list * exp 

= LET | LETREC | LETSTAR 


The BEGIN form is intended for use with primitive functions print1n and print. 


Except for VALREC, definitions are as in Scheme. 
405a. (definition of def for nano-ML 405a)= (S419b) 
datatype def = VAL of name * exp 
| VALREC of name * exp 
| EXP of exp 
| DEFINE of name * (name list * exp) 


In the operational semantics, nano-ML and juScheme have the same values, 
and their representations are similar enough that I can reuse the projection, em- 
bedding, and printing functions from Chapter 5. 


405b. (definition of value for nano-ML 405b) = (404) 
value = SYM of name 
| NUM of int 
| BOOLV of bool 
| NIL 
| PAIR of value * value 
| 


CLOSURE of lambda * value env ref 
| PRIMITIVE of primop 
withtype primop = value list -> value (* raises RuntimeError *) 
and lambda = name list * exp 


Only one thing is different: the representation of closures. 

A closure includes an environment, and if the closure represents a recursive 
function, the closure’s environment includes a reference to the closure itself. Such 
self-reference is implemented using mutation. In pScheme, the environment 
maps every name to a mutable reference cell. Recursion is implemented by first 
putting an unspecified value in the function's cell, then updating the cell once the 
closure is created. In nano-ML, an environment maps each name to a value—the 
mutable cell is part of the closure, not the environment. Recursion is implemented 
by first putting an unspecified environment in the closure’s cell, then building a 
new environment, and finally updating the cell to hold that environment. There- 
fore the closure stores a value env ref, not a value ref env as in puScheme. 


7.3. OPERATIONAL SEMANTICS 


Because nano-ML doesn’t have mutation and because the effects of its imperative 
primitives aren't specified formally, its operational semantics is simple. Its abstract 
machine has no locations and no store; evaluating an expression just produces a 
value. The judgment is (e, ») |} v. The environment p maps a name to a value, not 
to a mutable location as in wScheme. And evaluating a definition produces a new 
environment; the form of that judgment is (d, p) > p’. 


7.3.1 Rules for expressions 


Most of the rules should be self-explanatory. 


(LITERAL(v), p) J) v CITERSY) 
x € dom p 
(van (a), p) ¥ pa) ve 
(e1,p) vu, ~~ vy 4 BOOLV(#F) (€2, p) | ve (eTRUE) 
(IF(e1, €2, e3)) p) {ve 
(e1,p) v1 ~~ -v, = BOOLV(#F) (e3, p) 4} v3 tePAtse 


(IF(e1, €2; e3), p) 1) v3 
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The rules for BEGIN are a cheat; the purpose of BEGIN is to force order of evalua- 
tion, but these rules are so simplified that they don’t enforce an order of evaluation. 


EMPTYBEGIN 
(BEGIN(), ?) |) NIL ( ) 
(e1,p) 4% (€2,p) 4 v2 a (Cn, P) 4 Un 
(BEGIN) 
(BEGIN(€1, €2,---,€n); P) 4} Un 
Just as in zScheme, LAMBDA captures an environment in a closure, and APPLY 
ML and type : 

: uses the captured environment. Because nano-ML does not store actual parame- 

inference : 4 ; ; ; 

ters in mutable locations, its rules are simpler than pScheme’s rules. 

406 (MKCLOSURE) 


(LAMBDA((@1,..-,2n),€), P) 4) (LAMBDA((21,...,2n),e), p) 


(e, p) 4) (LAMBDA((21,..-,2n),€c), Pc) 
(ei,p) ui, LSicn 
(€e; Pe{L1 > U1, -+-,Ln > Un}) ev 
(APPLY(€, €1,---,€n),p) Yv 
The semantic rule for applying a nano-ML primitive is to apply the function 
attached to that primitive. The implementation is equally simple. 


(APPLYCLOSURE) 


(e, p) |) PRIMITIVE(f) 
(e;,py) yu, 1<i<n 
f(vi,..-,Un) =v 
(APPLY(€,€1,---,€n),p) v 
Because a LET-bound name stands for a value, not a location, rules for LET 
forms are also simplified. 


(APPLYPRIMITIVE) 


er pd wT ten 
(e, p{@1 4 U1,---, Ln > Un}) Lv 
(LET((21, €1, ete ,@n,€n)s ©), 0) a VU 


As in puScheme, a LETSTAR expression requires a sequence of environments. 


(LET) 


(€1,P0) 41 pp = po{t1 + v1} 


(e, Pn—1) a} Un Pn = Pn—14{2n, h> Un} 
(€, Pn) al Uv 


(LETSTAR((21,€1,---,2n,€n),€), Po) Vv 


(LETSTAR) 


LETREC is the tricky one. The expressions are evaluated in an environment p’ 
in which their names are already bound to the resulting values. In other words, 
to evaluate each e;, we have to have p’, but to build p’, we have to know all the v's. 
It seems like it should be impossible to make progress, but because the expressions 
are all lambda abstractions, we can pull it off. 


p' = p{x1 > U1,...,%n Un} 
fer,p) Yu + (ens p) 4 Un 
(e,p') vu 

(LETREC((21,€1,---;%n;€n),€), Pp) ev 

Because each e; is a LAMBDA, evaluating it is going to produce a closure that cap- 

tures p’ and the body of the LAMBDA. And in eval, that makes it possible to build p’ 

without calling eval recursively (chunk $430a). The resulting p’ satisfies the equa- 

tions in the premises, and the implementation closes the loop by stuffing p’ into 
the mutable cell contained in each closure. 


(LETREC) 


7.3.2 Rules for evaluating definitions 


In puScheme or Typed pScheme, evaluating a definition produces a new environ- 
ment and a new store. In nano-ML, because there is no mutation, evaluating a def- 
inition produces only a new environment. (It may also print.) The judgment has 
the form (d, p) > p’. 

Nano-ML’s definitions differ from wScheme’s in several significant ways: 


* In nano-ML, asin full ML andin Typed ~wScheme, a VAL definition never mu- 
tates a previous binding; it always adds a new binding. (See Exercise 46 on 
page 194 of Chapter 2.) If the old binding was used to create a function or 
other value, that function still refers to the old binding, not the new one. 
In an interactive interpreter, this behavior can be baffling, particularly if you 
load a new definition of an old function but you don’t also load the definitions 
of the functions that depend on it. 


(e,p) Yv 


Wana, e),p) — pla o} oe 


Like Typed wScheme but unlike Scheme, nano-ML has VAL-REC. The se- 
mantics requires a p’ that binds f to a closure containing p’. 


p’ = p{f O (LAMBDA((71,.-.,2n),e), p’ )} 
(VAL-REC(f, LAMBDA((%1,..-,2n),€)),P) > p! 


(VALREC) 


This self-reference is implemented using the same mutable-cell trick used to 
implement LETREC. 


In nano-ML, as in Typed Scheme, DEFINE(f,a,e) is syntactic sugar for 
VAL-REC(f, LAMBDA(a, €)). 


(VAL-REC(f, LAMBDA((X1,..-,2n),€));p) > p" 


(DEFINE(f, (21,---;n),e), p) > p’ (DEFINE) 


As in wScheme, a top-level expression e€ is syntactic sugar for a binding to it. 


(vAL(it, €), p) > p’ 


(ExP(e), p) — p’ mies 


7.4 TYPE SYSTEM FOR NANO-ML 


Like other type systems, the type system of nano-ML determines which terms have 
types, which in turn determines what definitions are accepted by the interpreter. 
As before, the types of terms are specified by a formal proof system. The system 
uses the same elements as the type system of Typed psScheme. 


7.4.1 Types, type schemes, and type environments 
As in Typed jsScheme, types are built using four elements: 


* Type variables, which are written using a 


* Type constructors, which are written generically using js or specifically using 
a name such as int or list 


* Constructor application, which is written using ML notation (71,..., 7) T 


* Quantification, which is written using V 
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In nano-ML, unlike in Typed psScheme, quantified types are restricted: a type quan- 
tified with V may appear only at top level, never as an argument to a type construc- 
tor. In nano-ML, this restriction is built in to the syntax of types: 


+ A type built with type variables, type constructors, and constructor applica- 
tion is written using the metavariable rT. 


T =o) ji | Gaiseoreae) 
ML and type . 
inference AT is called a type. 
408 + A quantified type is written using the metavariable o. 


ao 2=Vay,...,An-T 
Ac is called a type scheme. 


In the code, aT is represented by a ty andao by a type_scheme:” 


408. (representation of Hindley-Milner types 408) = (S420a) 
type tyvar = name 
datatype ty = TYVAR of tyvar (* type variable alpha *) 
| TYCON of tycon (* type constructor mu *) 
| CONAPP of ty * ty list (* type-level application *) 


datatype type_scheme = FORALL of tyvar list * ty 


The set of type schemes o in which the a1,..., Qn is empty is isomorphic to 
the set of types 7. The isomorphism relates each type tau to the type scheme 
FORALL([], tau). A type without V or a type scheme in which the ay,...,@p is 
empty is sometimes called a monotype or ground type. A type scheme in which the 
Q1,...,Q@,, is not empty is sometimes called a polytype. 

When a type application appears in code, the type constructor goes before its 
arguments, as in 


CONAPP(TYCON "list", [TYCON "int"]). 


But in the text, the type constructor goes after its arguments, as in int list. This 
is the way types are written in ML source code. 

In nano-ML, all type constructors are predefined; no program can add new 
ones. New type constructors can be added in the more advanced bridge languages 
[ML (Chapter 8) and Molecule (Chapter 9). In nano-ML, the predefined construc- 
tors arguments and function appear in the typing rules for functions. Other con- 
structors, like bool, int, sym, and so on, give types to literals or primitives. 

To write types made with arguments and function, I use ML’s abbreviations. 


Type Abbreviation 
(71,72) function TS T2 
(T1,---,7) arguments 71 X T2°+* X Tp 


In nano-ML, as in Typed Scheme, a type environment is written using the 
Greek letter I. In nano-ML, a type environment I’ maps a term variable ? to a type 
scheme. Type environments are used only during type inference, not at run time. 


*Nano-ML’s representation has only four of the five forms found in Typed Scheme. The fifth form, 
FUNTY, is represented in nano-ML as a nested application of type constructors function and arguments 
(chunk 412b). Coding function types in this way simplifies type inference. 

3Term variables, which appear in terms (expressions) and are bound by let or lambda, stand for 
values. Don’t confuse them with type variables, which stand for types. The name of a term variable 
begins with a letter or symbol; the name of a type variable begins with the ASCII quote (') character. 


In nano-ML, unlike in Typed jsScheme, types don’t appear in code. And types 
inferred by the system are guaranteed to be well formed, so the type system doesn't 
need formation rules or kinds. (An ill-formed type may appear in a unit test, but in 
that case the test just fails; no other checking is needed.) Kinds are used again in 
[ML (Chapter 8) and in full ML. 


7.4.2 Simple type constructors $7.4 


Type system 


Because all type constructors are predefined, a type constructor can be represented Joi nana ML 


simply by its name. Because type names cannot be redefined, a name like int al- 
ways means “integer,” and two type constructors are the same if and only if they 409 
have the same name. 


409a. (tycon, eqTycon, and tyconString for named type constructors 409a) = ($420a) 
type tycon = name type tycon 
fun eqTycon (mu, mu') = mu = mu' eqTycon : tycon * tycon -> bool 
fun tyconString mu = mu tyconString : tycon -> string 


7.4.3 Substitution, instances, and instantiation 


In nano-ML, the system automatically instantiates polymorphic values. To show 
how this feature works, I define empty-list with type Va . a list, then let the 
system instantiate it at types int and sym list: 
409b. (transcript 402) += 1402 414> 

-> (val empty-list '()) 

() : (forall ['a] (list 'a)) 

-> (val p (pair (cons 1 empty-list) (cons '(a b c) empty-list))) 

(PAIR (1) ((a bc))) : (pair (list int) (list (list sym))) 
In Typed wScheme, empty-list would have to be instantiated explicitly, using ex- 
pressions (@ empty-list int) and (@ empty-list (list sym)). Likewise, primi- 
tives pair and cons would have to be instantiated explicitly. These instantiations 
are what Professor Milner found intolerable. In ML, no @ form is needed; every 
polymorphic name is instantiated automatically by Milner’s inference algorithm. 
The algorithm works by computing an appropriate substitution. 

A substitution is a finite map from type variables to types; one is written using 

the Greek letter 6 (pronounced “THAYT-uh”). A 6 has many interpretations: 


« Asa function from type variables to types 

« Asa function from types to types 

« Asa function from type schemes to type schemes 

- Asa function from type environments to type environments 


« As a function from type-equality constraints to type-equality constraints cons P 440a 
type name 303 


- Asa function from typing judgments to typing judgments Bate Pp 


- Asa function from typing derivations to typing derivations 


These interpretations are all related and mutually consistent. They all appear in 
the math, and some appear in my code. The interpretation I use most is the func- 
tion from types to types. Such a function 6 is a substitution if it preserves type 
constructors and constructor application: 


+ For any type constructor pl, Ou = po. 
- For any constructor application CONAPP(T, (71,---,7n))5 


O(CONAPP(T, (71, ---,7n))) = CONAPP(OT, (07),...,9Tp)). 
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Or, using informal ML-like notation, 
O((71, +--+; Tn) T) = (O71,..-,O7) (Or). 


In the common case where the 7 being applied is a simple constructor ju, 
Ou = and 
O((71,--+5 Tn) B) = (071,.--, OT) b- 


To be a substitution, a function from types to types must meet one other condition: 


* The set {a | 6a # ax} must be finite. This set is the set of variables substi- 
tuted for. It is called the domain of the substitution, and it is written dom @. 


Such a function is defined by tysubst in Chapter 6 on page 371; its inner function 
subst has all the properties claimed above (Exercise 3). 

Substitution determines when 7’ is an instance of T: like Milner (1978), we write 
tv’ < 7 if and only if there exists a substitution 6 such that r’ = 67. The instance 


“ls 


relation r’ < 7 is pronounced in two ways: not only “r’ is an instance of r” but also 
“r is at least as general as r’.” 

The instance relation is extended to type schemes: 7’ < Vay,...,Q@, .7T ifand 
only if there exists a substitution 6 such that dom C {aj,...,@n}and 67 = 71’. 
The first condition says that the instantiating substitution # may substitute only for 
type variables that are bound by the V. 

To instantiate a type scheme o = Vaj,...,Qn .T isto choosear’ < co. Anin- 
stance of o is obtained by substituting for the type variables a1,...,an, and only 
for those type variables. It’s like instantiation in Typed jsScheme, except in ML, the 
system instantiates each o automatically. 

In my code, a substitution is represented as a finite map from type variables 
to types: an environment of type ty env. A substitution’s domain is computed by 
function dom. 


410a. (shared utility functions on Hindley-Milner types 410a)= (S420a) 410b > 
type subst = ty env type subst 
fun dom theta = map (fn (a, _) => a) theta dom : subst -> name set 


To interpret a substitution as a function from type variables to types, we apply 
varsubst to it: 


410b. (shared utility functions on Hindley-Milner types 410a) += (S420a) <1410a 410c> 


fun varsubst theta = varsubst : subst -> (name -> ty) 


(fn a => find (a, theta) handle NotFound _ => TYVAR a) 


As the code shows, the function defined by a substitution is total. If type variable a 
is not in the domain of theta, then varsubst theta leaves a unchanged. 

A substitution is most often interpreted as a function from types to types. That 
interpretation is provided by function tysubst. Itis almost the same as the tysubst 
function in the interpreter for Typed zScheme (page 374), but because it has no 
quantified types to deal with, it is simpler. 


410c. (shared utility functions on Hindley-Milner types 410a) += (S420a) <410b 411a> 
fun tysubst theta = tysubst : subst -> (ty -> ty) 
let fun subst (TYVAR a) = varsubst theta a] subst : ty -> ty 


| subst (TYCON c) = TYCON c 
| subst (CONAPP (tau, taus)) = CONAPP (subst tau, map subst taus) 
in subst 
end 


A function produced by tysubst has type ty -> ty and so can be composed 
with any other function of the same type, including all functions that correspond 


to substitutions. To be precise, if 6; and 02 are substitutions, then the composition 
tysubst @2 0 tysubst 0, is a function from types to types (and also corresponds 
to a substitution). Composition is really useful, but a substitution data structure 0 
is strictly more useful than the corresponding function tysubst 6. For one thing, 
@ can be asked about its domain. To compose substitutions in a way that lets me 
ask about the domain of the composition, I define a function compose, which obeys 
these algebraic laws: 


tysubst(compose(62, 0,)) = tysubst 02 0 tysubst 61, 
dom(compose(O2, 61)) = dom 6; U dom 6p. 


Alla. (shared utility functions on Hindley-Milner types 410a) += (S420a) <31410c 411b> 


: subst * subst -> subst 


fun compose (thetae, thetal) = pomp ose 


let val domain = union (dom theta2, dom theta1) 
val replace = tysubst thetae o varsubst thetal 


in mkEnv (domain, map replace domain) 
end 


Instantiation is as in Chapter 6, except no kind environment is needed. Because 
instantiations are computed by the system, instantiating a type scheme with the 
wrong number of arguments indicates an internal error. Such an error is signaled 
by raising the exception BugInTypeInference, which is raised only when there is a 
fault in the interpreter; it should never be triggered by a faulty nano-ML program. 
411b. (shared utility functions on Hindley-Milner types 410a) += ($420a) <41la 411¢> 
instantiate : type_scheme * ty list -> ty 
fun instantiate (FORALL (formals, tau), actuals) = 

tysubst (mkEnv (formals, actuals)) tau 
handle BindListLength => 
raise BugInTypeInference "number of types in instantiation" 


All substitutions can be built with mkEnv, but that’s not how Milner’s algorithm 
creates them. Milner’s algorithm substitutes for one type variable at a time, then 
composes those substitutions. To create a substitution that substitutes for a sin- 
gle variable, I define an infix function |-->. The expression alpha |--> tau is the 
substitution that substitutes tau for alpha. In math, that substitution is written 
(a+ 7). 
411c. (shared utility functions on Hindley-Milner types 410a) += (S420a) <411b 411d> 


|--> : name * ty -> subst 


infix 7 |--> 
fun a |--> (TYVAR a') = if a = a' then emptyEnv 
else bind (a, TYVAR a', emptyEnv) 
| a |--> tau = bind (a, tau, emptyEnv) 


The |--> function accepts any combination of a and T. But if a appears free in T 
(for example, if 7 = a list), then the resulting substitution 6 is not idempotent. 
If # is not idempotent, then 0 o 6 4 0, and moreover, Oa 4 Or. But type inference 
is all about using substitutions to guarantee equality of types, and we must be sure 
that every substitution we create is idempotent, so if 9 = (a ++ 7), then 0a = 07. 
If this equality does not hold, there is a bug in type inference (Exercise 2). 

A final useful substitution is the identity substitution, which is represented by 
an empty environment. 
411d. (shared utility functions on Hindley-Milner types 410a) += 

val idsubst = emptyEnv 


($420a) <411c 412ap 


idsubst : subst 


In math, the identity substitution is written 07, and it is a left and right identity of 
composition: 6; 06 = 606; =9@. 
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My representation of substitutions is simple but not efficient. Efficient imple- 
mentations of type inference represent each type variable as a mutable cell, and 
they apply and compose substitutions by mutating those cells. 


7.4.4 Functions that compare, create, and print types 


Because a Hindley-Milner type contains no quantifiers, type equivalence is easier 
to define than in Typed wScheme (chunk 370a). 


412a. (shared utility functions on Hindley-Milner types 410a) += (S420a) 411d 433bp> 
fun eqlype (TYVAR a, TYVAR a') =a =a!' eqlype : ty * ty -> bool 

| eqType (TYCON c, TYCON c') = eqTycon (c, c') 

| eqType (CONAPP (tau, taus), CONAPP (tau', taus')) = 
eqlype (tau, tau') andalso eqTypes (taus, taus') 


| eqType _ = false 
and eqlypes (taus, taus') = ListPair.allEq eqType (taus, taus') 


The types of primitive operations are written using convenience functions very 
much like those from Chapter 6. 


412b. (creation and comparison of Hindley-Milner types with named type constructors 412b) = 


val inttype = TYCON "int" inttype : ty 
val booltype = TYCON "bool" booltype : ty 
val symtype = TYCON "sym" symtype BEY 
val alpha = TYVAR "a"! alpha : ty 
val beta = TYVAR "b" beta : ty 
val unittype = TYCON "unit" unittype : ty 
fun listtype ty = listtype : ty -> ty 
CONAPP (TYCON "list", [ty]) pairtype : ty * ty -> ty 
fun pairtype (x, y) = funtype : ty list * ty -> ty 
CONAPP (TYCON "pair", [x, y]) asFuntype : ty -> (ty list * ty) option 


fun funtype (args, result) = 

CONAPP (TYCON "function", [CONAPP (TYCON "arguments", args), result]) 
fun asFuntype (CONAPP (TYCON "function", 

[CONAPP (TYCON "arguments", args), result])) = 
SOME (args, result) 
| asFuntype _ = NONE 
To make it possible to print types and substitutions, Appendix R defines func- 
tions typeString, typeSchemeString, and substString. 


7.4.5 Typing rules for nano-ML 


In Typed Scheme, you may define and use quantified types anywhere, but you 
must write type-lambda and @ everywhere. As shown in Chapter 6, writing these 
type abstractions and type applications explicitly is tiresome. And in ML, type ab- 
straction and type application are done for you; the only downside is that ML can 
express fewer types than Typed Scheme. In ML, the V quantifier appears only 
in a type scheme, never in a type, and a function cannot expect an argument of a 
quantified type. 

To fill in the missing type abstractions and instantiations, nano-ML’s type sys- 
tem does more work than a type checker for Typed puScheme: 


* When a value is polymorphic, the code doesn’t say how to instantiate it; the 
type system has to figure out a type at which the value should be instantiated. 


* When a function is defined, the code doesn’t state the types of its arguments; 
the type system has to figure out a type for each argument. 


instantiate (use name) 


name in T° e (or x) 


on 


(2-- 
generalize (bind name with val or let) 


Figure 7.2: Relationship between type schemes and types 


The types can be figured out because in the Hindley-Milner type system, V cannot 
appear just anywhere. In particular, it cannot appear in the type of an expression: 
every well-typed expression has a monotype, although the monotype may have free 
type variables. Only a name bound in the environment may have a polytype. When a 
name from I is used as an expression, its type scheme is instantiated to give it a 
monotype. This instantiation amounts to an implicit @ operation. When a name 
is bound by val or let, the type of its right-hand side is generalized to make a type 
scheme, which is then put into the environment. This generalization amounts to 
an implicit type-lambda operation. Instantiation and generalization are depicted 
in Figure 7.2. (There’s also a sidebar on page 435.) 

When a type is instantiated, what types should be substituted for the type vari- 
ables? When a function's type is determined, what types should the arguments 
have? Luckily, these questions don’t have to be answered right away. Nano-ML’s 
type system can be described by nondeterministic rules that show a type 7 without 
saying how 7 is computed. Those rules take up the rest of this section. In Sections 
7.5.1 and 7.5.2, the nondeterministic rules are refined into new rules that specify a 
deterministic type-inference algorithm. 


Nondeterministic typing rules for expressions 


The typing judgment for an expression has the form I + e : 7, meaning that 
given type environment I’, expression € has type 7. An expression may have more 
than one type; for example, the empty list has many types, and the judgments 
IF LITERAL(NIL) : int list and’ + LITERAL(NIL) : bool list are both valid. 

A use of a variable is well typed if the variable is bound in the environment. 
The variable’s type is not fully determined; it may have any type that is an instance 
of its type scheme. 

I(x) =o T<o 
PR aet 

Unlike our rules for operational semantics, this rule does not specify a determin- 
istic algorithm. Any 7 that is an instance of o is acceptable, and the rule does not 
say how to find the “right” one. A 7 is determined by the algorithm in Section 7.5.2, 
which finds a most general rT (Exercise 5). 

A conditional expression is well typed if the condition is Boolean and the two 
branches have the same type 7. The conditional expression also has type T. 


(VAR) 


T+ e; : bool Tbh e9:7T Th e3:T 


TF 1F(e1, €2, €3) : T (F) 
A sequence is well typed if its subexpressions are well typed. 
gerne oe 
An empty BEGIN is always well typed with type unit. 
(EMPTYBEGIN) 


TF BEGIN() : unit 
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An application is well typed if the function has arrow type, and if the types and 
number of actual parameters match the types and number of formal parameters 
on the left of the arrow. 


Tre:%, L<i<n The:% X+++X mT 
[TF APPLY(e, €1,..-,€n):T 


(APPLY) 


A function is well typed if, in an environment that binds each formal parameter 
to its type, the function’s body is well typed. The type of the function is formed from 
the types of its formal parameters and its body. 


T{ap ],...,Unt> Tmhbe:r 
(LAMBDA) 
TF LAMBDA((21,...,2n),€) 271 X +++ X Tn OT 
Like the VAR rule, the LAMBDA rule is nondeterministic; types 71,..., 7 arentin 


the syntax, and the rule doesn’t say what they should be. 

In the LAMBDA rule, the notation {x; +> 7;} is shorthand for {x; > V.7;}5 
each 7; is converted into a type scheme by wrapping it in an empty V. The type 
scheme Y.7; has only one instance, which is 7; itself. Therefore, when x; is used 
in e, it always has the same type. This rule restricts the set of functions that can 
be given types: an ML programmer cannot define a function that requires its argu- 
ments to be polymorphic. No matter how polymorphic an actual parameter may 
be, inside the function the formal parameter has just one type. The restriction helps 
make type inference decidable. 

The restriction can be illustrated by comparing two bindings. If empty-list is 
defined as a global variable and is bound to the empty list, then it has a polymor- 
phic type scheme, and both an integer and a boolean can be consed onto it. But if 
empty-list is defined as a formal parameter, then no matter what actual parame- 
ter it is eventually bound to, it cannot be polymorphic: 

414. (transcript 402) += <1409b 415> 

-> (val empty-list '()) 

() : (forall ['a] (list 'a)) 

-> (val p (pair (cons 1 empty-list) (cons #t empty-list))) 

(PAIR (1) (#t)) : (pair (list int) (list bool)) 

-> (val too-polymorphic 

(lambda (empty-list) (pair (cons 1 empty-list) (cons #t empty-list)))) 

type error: cannot make int equal to bool 
Because the val definition form corresponds to a let, the difference shown here 
is usually called the difference between a lambda-bound variable and a let-bound 
variable. The difference can be formalized in a typing rule. 

The simplest possible rule describes MLET, a restricted form of LET that binds 
a single variable. When z is bound in I’, x is given a type scheme that may quantify 
over a nonempty set of type variables and so may be polymorphic: 


Tre:7' — ftv(r’) — ftv(P) = {a1,..., an} 
T{ar Vay,...,Qn.T/h} re: 
[TF MLET(2z, e’,e) : 7 


(MILNER’S LET) 


The set {a1,...,@,} is the difference of two sets computed with ftv, a function 
that finds free type variables. Operationally, a type checker first finds 7’, the type 
of e’, but it doesn’t simply extend [ with {2 +> 7’}. Instead, using V, it closes 
over the free type variables of r’ that are not also free type variables of types in I. 
Milner discovered that if a type variable isn’t mentioned in the environment, it can 
be instantiated any way you want, and it can even be instantiated it differently at 
different uses of x. Closing over such type variables might give x a polymorphic 


type scheme. For example, in the following variation on too-poly, the let-bound 
variable empty-list gets a polymorphic type scheme, and when the polymorphic 
empty-list is used, it is instantiated once with int and once with bool. 
415. (transcript 402) += 1414 417ap 

-> (val not-too-polymorphic 

(let (Lempty-list '()]) 
(pair (cons 1 empty-list) (cons #t empty-list)))) 

(PAIR (1) (#t)) : (pair (list int) (list bool)) 

If let-bound variables might be polymorphic, why not \-bound variables? 
A-bound variables can’t be made polymorphic because the type checker doesn't 
know what type of value a A-bound variable might stand for—it could be any actual 
parameter. By contrast, the type checker knows exactly what type of value a let- 
bound variable stands for, because it is right there in the program: it is the type 
of e’. If e’ could be polymorphic (because it has type variables that don’t appear 
in the environment), that polymorphism can be made explicit in the type scheme 
associated with x. 

The polymorphic MLET is sometimes called “Milner’s let.” Milner’s let is type- 
checked with the help of a new operation on types: generalization. Generalization 
is defined by function generalize, which takes as argument a type 7 and a set of 
constrained type variables A: 


generalize(r, A) = Vaj,...,Q@,.7, where {a1,...,Qn} = ftv(7) — A. 


Often A is the set of type variables that appear free in a type environment, e.g., 
A = ftv(T). As suggested in Figure 7.2 on page 413, generalization is like an in- 
verse of instantiation: for any 7 and I, it’s true that 7 < generalize(r, ftv(I)). 
Function generalize is implemented in code chunk 434b. 

Using generalize, the rule for Milner’s let is written as follows: 


Tre’:7r’ o=generalize(r’,ftv([)) T{rtro}Fe:r 
[TF MLET(2, e’,e) : 7 


(MILNER’S LET) 
The corresponding rule for nano-ML’s LET, which simultaneously binds multiple 
names, has a premise that generalizes the type of each e;, and its environment 
binds each x; to its corresponding type scheme oj. 


Tke:%, L<i<n 
oj = generalize(7;,ftv([)), lL<i<n 
T{a1 01,...,an onpre:T 
TE LET((a1,€1,---,;%n,€n),€) 2 T 


(LET) 


The typing rule for LETREC is similar, except that the e;’s are checked in type 
environment I”, which itself contains the bindings for the x,’s. Environment I” is 


defined using the set {71,...,7,}, and each type 7; is in turn computed using I’. 
So I” is defined in terms of itself, using types 71, ... , Tn as intermediaries: 
IY =T{a, ,...,2n > Tr} 


MFre:%, L<i<n 
oj = generalize(7;,ftv(T)), lL<i<n 
T{ay > o1,...,2n tO onfbe:r 
TF LETREC((21,€1,---,;%n,€n),€) 3 T 


(LETREC) 


Within I”, the variables x; are not given polymorphic type schemes. Only once all 
the types of the e;’s are fixed can the types of the x,’s be generalized and used to 
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compute the type of e. A LETREC defines a nest of mutually recursive functions, and 
because generalize is not applied until the types of all the functions are computed, 
these functions are not polymorphic when used in each other's definitions—they 
are polymorphic only when used in e. This rule can surprise even experienced ML 
programmers; in the presence of letrec, functions that look polymorphic may be 
less polymorphic than you expected. 

Arule for LETSTAR would be annoying to write down directly: there is too much 
bookkeeping. Instead, LETSTAR is treated as syntactic sugar for a nest of LETs. 


T+ LeT((1, €1), LETSTAR((%2,€2,-.-,%n,€n),€)):T n>O Ginestin) 
TF LETSTAR((21,€1,---,;%n,€n),€) 2 T 
Thre: 
(EMPTYLETSTAR) 


I+ LETSTAR((),e€) : 7 


Typing rules for definitions 


In the operational semantics, a definition produces a new value environment. 
In the type system, a definition produces a new type environment. The new en- 
vironment is given by a judgment of the form (d,I’) > I”, which says that when 
definition d is typed in environment I’, the new environment is I’. 

A VAL binding is just like Milner’s let binding, and it has almost the same rule. 


[TFe:t  o =generalize(r, ftv([)) 


(vat(a,€),1) oT {ao} wey) 


VAL-REC requires that a recursive value be defined in the environment used to 
find its type. 


I{arn rh e:rt  o =generalize(r, ftv(T)) 


VALREC 
(VAL-REC(a, e),T) > {aH o} ( ) 
A top-level expression is syntactic sugar for a binding to it. 
vAL(it, e),) > I” 
(vat (it, €),P) ee 


(eExP(e),T) + I’ 
A DEFINE is syntactic sugar for a combination of VAL-REC and LAMBDA. 


(VAL-REC(f, LAMBDA((21,...,%n),e)), EF) > I” 
(DEFINE(f, ((@1,.--,2n),e)), 0) > I” 


(DEFINE) 


7.4.6 Nondeterministic typing, principal types, and type testing 


Nondeterministic typing rules can’t easily be used directly; the judgment | e: + 
can often be proved for infinitely many types 7. Fortunately, in the Hindley-Milner 
type system, if there is any such 7, then there is a principal type Tp, to which every 
other 7 is related. A principal type of e is at least as general as every other type of e. 
That is, if Tp is a principal type of e, andif[' + e: 7, then < Tp. Therefore every 
type of e can be obtained by substituting for free type variables of Tp. 

The idea of principality can be extended to type schemes. To do so, we relate 
two type schemes in the same way that we relate types in Typed wScheme: a, is at 
least as general as o;, written o; < dq, if a; can be obtained from a, by substitution 
and by reordering of type variables. (Because nano-ML has no explicit instantiation, 
the order of type variables doesn’t matter, and two type schemes that differ up to 


permutations of type variables are equivalent.) Equivalently, 0; < o, if and only if 
0, has all of o;’s instances. That is, whenever 7 < oj, itis also true that T < oy. 

Given that relation, type scheme ¢ > is a principal type scheme of e in environ- 
ment I if there is a derivation of (VAL(x,e),[) > I'{a ++ op}, and furthermore, 
whenever there is a o such that (vAL(x,e),C) > T{a+> o}, theno < o>. 

In nano-ML, generality and principality can be unit-tested. Using check-type, 
an expression’s type is compared with a given type scheme. If the expression’s type 
is at least as general as the given type scheme, the test passes. For example, the 
following tests both pass: 

417. (transcript 402) += 415 423> 
-> (define arg1 (x y) x) 
-> (check-type argi (forall ['a 'b] ('a 'b -> 'a))) ; the principal type 
-> (check-type argi (forall ['a] C'a 'a -> 'a))) ; a less general type 
Essentially, (check-type e a) checks if a variable defined equal to e can be bound 
into the type environment with type scheme o—that is, if there can be a derivation 
of (vAL(x, e),T) > {a o}. 

To test exactly what type a function has, use a check-principal-type test. 

417b. (principal-types.nml 417b)= 417c> 
(define arg1 (x y) x) 
(check-principal-type arg1 (forall ['a 'b] ('a 'b -> 'a))) ; pass 
(check-principal-type arg1 (forall ['a] ('a ta -> 'a))) ; FAIL 

As another example, length has many types and many type schemes, but only one 

principal type scheme: 


417¢. (principal-types.nml 417b) += <1417b 
(check-type length ((list int) -> int)) ; pass 
(check-principal-type length ((list int) -> int)) ; FAIL 
(check-type length (forall ['a] ((list (list 'a)) -> int))) ; pass 
(check-principal-type length (forall ['a] ((list (list 'a)) -> int))) ; FAIL 
(check-type length (forall ['a] ((list 'a) -> int))) ; pass 


(check-principal-type length (forall ['a] ((list 'a) -> int))) ; pass 


The implementations of check-type and check-principal-type, which are found 
in Appendix R on page S427, use the < relation on type schemes. 


7.5 FROM TYPING RULES TO TYPE INFERENCE 


The nondeterministic typing rules don’t specify an algorithm that can decide if a 
nano-ML term has a type, let alone find a principal type. That is, given I‘ and e, 
the rules don’t say how to find a 7 such that + e : 7. The LAMBDA rule doesn't 
specify the types of the formal parameters, and the VAR rule doesn’t specify which 
instance of o to use as T. But these rules can be used in an algorithm ifthe algorithm 
uses a trick: whenever a type is unknown, the algorithm identifies that type with 
fresh type variable. For example, when a LAMBDA takes an argument 2;, x;’s type 
is recorded as a, where a; is a new type variable that is not used anywhere else in 
the program. The a; stands for an unknown type, and the way 7; is used might tell 
us something about it. For example, if x; were added to 1, that would tell us that a; 
has to be equal to int. Eventually int would be substituted for a;. 

How does an algorithm discover what type to substitute for each fresh type vari- 
able? There are two good methods: 


* The first method is the method of explicit substitutions. When the type 
checker wants two types to be equal, it calls ML function unify(7, 72). Auni- 
fication algorithm returns a 0 such that 0(7,) = 6(72); substitution 6 is called 
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a unifier of T; and T2. These substitutions are composed to implement type 


inference: given I and e, the algorithm can find 6 and7 such that| OC | e: 7 | 


The method of explicit substitutions is described by simple mathematics and 
is easy to prove correct, but it generates an awful lot of substitutions, which 
have to be composed in exactly the right order. And it is easy to forget to 
apply a substitution; in short, the implementation is hard to get right. 


* The second method is the method of type-equality constraints. When the type 
checker wants two types 7; and 72 to be equal, it doesn’t unify them right 
away. Instead, it remembers the constraint T, ~ T2, which says that 7; must 
equal 72. If the type checker needs two or more such constraints, it conjoins 
them into a single constraint using logical and, asin C \C2. The constraints 


are used in a judgment of the form| C, Fe: r |. 


The method of explicit constraints is described by more elaborate mathe- 
matics and is not as easy to prove correct, but the composition operation / 
is associative and commutative, so unlike substitutions, constraints can be 
composed in any order—there’s no wrong way to do it. Using constraints, 
most of type inference is not so hard to get right. 


In the method of explicit constraints, unification happens lazily: when it sees 
a LET binding or a VAL binding, the type checker calls on a constraint solver to 
produce a substitution that makes the constraints true. The constraint solver 
does the same job as unify, and solving constraints is only a little bit more 
complicated than unifying types. And with a constraint solver, implement- 
ing type inference itself is infinitely easier. For this reason, the method of 
explicit constraints is the one that I recommend. 


Both methods of type inference are justified by the same principle: if in a valid 
derivation, we substitute for free type variables, the new derivation is also valid. 
D 0D 
That is, if feces is a valid derivation, then for all substitutions 0, Orb be Or 
is a valid derivation. 
Which method should you study? It depends what you want to do. 


¢ If you want to read original, primary sources, study explicit substitutions, 
because that’s what Milner (1978) describes. 


* Ifyou want to prove that type inference is consistent with the nondeterminis- 
tic type system in Section 7.4.5 (Exercise 11), study explicit substitutions—the 
proof is much easier. 


* If you want to build something (Exercises 18 and 19), study type-equality 
constraints—the code is much easier. 


7.5.1 The method of explicit substitutions 


Milner’s original type-inference algorithm uses explicit substitutions. To under- 
stand explicit substitutions in detail, we can start by developing a syntactic proof 
system for judgments of the form 61 | e : r. Such a proof system would contain 
this rule for IF: 


ail fF €, 2 T1 62(A:T) E €2:72 63(02(@:T)) -E €3 : T3 
0(0372) => 0(73) =T 
6'(0(03(02(71)))) = 0’(bool) 


I 
(0 060 @3 0 82 061) TF IF(e1, €2, €3) : OT F) 


The rule can be interpreted operationally as part of an algorithm that takes [ and e 
as inputs and produces 7 and @ as outputs. 


1. Infer type 71 for e1, producing substitution 61. 


2. Apply 0) to the environment I, and continue in similar fashion, inferring 
types and substitutions from e2 and e3. 


3. Unify types 6372 and 73, producing a new substitution @. The resulting type T 
becomes (after one more substitution) the type of the entire IF expression. 


4. Unify the type of e; with bool, producing substitution 6’. Be careful to apply 
proper substitutions. 


5. Return the composition of the substitutions, together with 6’r. 


This new rule is sound, which means that whenever there is a derivation us- 
ing the new IF rule, there is a corresponding derivation using the original IF rule. 
A real proof of soundness is beyond the scope of this book (Exercise 11), but to help 
you understand how the system works, here is a hand-waving argument: To prove 
soundness, we rewrite derivations systematically so that if we are given a deriva- 
tion in the new system, we can rewrite it into a derivation in the old system. In the 
case of the IF rule, we rewrite (6/0 0063 002 06,)TasT, (000063063) 7 as 74, 
and so on. For example, if 6, | e1 : 71, we apply substitution (6 o 6 0 @3 0 82) to 
both sides, rewrite, and the premise becomes equivalent to Phe, : 7. Asimilar 
rewriting of all the premises enables us to apply the original IF rule to draw the 
conclusion. 

Although the new IF rule is sound, and it has a clear operational interpreta- 
tion, it requires a lot of explicit substitutions; it’s a bookkeeping nightmare. But the 
bookkeeping can be reduced by a trick: extend the typing judgment to lists of ex- 
pressions and types. Write OF e€1,...,@€n : T1,.-.,7 as an abbreviation for a set 
of n separate judgments: 6[ fe, : 7, ... ,O F en : Tr. When n = 1, this judg- 
ment degenerates to O[' F e, : 7. For n > 1, finding the common substitution 6 
requires combining substitutions from different judgments. 


OP Fe: 71 O'(OT) F €2,..-,€n 2 T2;-++5Tn 
(8 of)TF e4,...,€n : O71, 72,---,Tnr 


(TYPESOF) 


This new judgment can be used to reduce the number of substitutions in any rule 
that has multiple subexpressions, like IF. For example, the application rule can be 
written like this: 


OIG xO yy 2nd nCn oP Te hige ss 5 Tn 
O'(7) = O'(11 X +++ X Tn — a), where ais fresh 
(00 0)T'F apPLly(e,€1,...,€n) : Wa 


(APPLY) 


The most difficult rule to express using explicit substitutions is probably LE- 
TREC. The nondeterministic rule is 


IY =Tf{aj, 4,...,2n + Tr} 
re: l<i<n 
oj = generalize(7;,ftv(T)), lL<i<n 
T{ay > o1,...,2n te onbbe:r 
TF LETREC((21,€1,---,;%n,€n),€) 3 T 


(LETREC) 
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The rule with explicit substitutions is 


IY =Tf{a, a,...,2n ++ An}, where all a;’s are fresh 
OD Pieigeis On STi tes TH 
O'7, =0'(0a;), L<i<n 
o; = generalize(0’7;, ftv((0’0@)T)), L<i<n 
"(8 OO)T) {x1 4 O1,...,2n A on}) Fert 
(0” 0 & of)T FE LETREC((21, €1,---;%n,€n),€) 2 T 


(LETREC) 


The soundness proof must show that the substitution 6” does not change any type 
variable that is bound in any o;. 

Using explicit substitutions, rules like LETREC are hard to implement: not only 
must you compose three or more substitutions, but you must compose them in 
the right order, and you must apply certain substitutions or even compositions 
(like 6’ o 6) to one or more arguments of other calls. In my experience, people who 
tackle this implementation task almost always forget a substitution somewhere, 
leading to an implementation of type inference that almost works, but not quite. 
There is a better way. 


7.5.2 The method of explicit constraints 
To find that better way, we return to the nondeterministic type system of Sec- 
tion 7.4.5. Ina rule like 


T+ e; : bool Th eg:T Tb e3:7 
TF 1F(ey, €2, €3) oat : 


(IF) 


expression €, angelically has the right type bool, and e2 and e angelically have the 
same type T. Instead of requiring angels, the method of explicit constraints allows 
each e; to have whatever type it wants, which I'll call 7;. Then the type checker 
insists that 7; must equal bool and 72 must equal 73. Its insistence is recorded in 
an explicit constraint C’, which is added to the typing judgment as part of the typing 
context. For the IF rule, the constraint Cis 7] ~ bool \ 72 ~ 73. Operators ~ and A 
are explained below. 

Using explicit constraints, a typing judgment has the form C,ITF e : 7, which 
means “assuming the constraint C is satisfied, in environment I term e has type T.” 
Constraints are formed by conjoining simple equality constraints: 


* A simple equality constraint has the form 7; ~ 72 (pronounced “7; must 
equal 72”), and it is satisfied if and only if the types 7, and 72 are equal. 


* A conjunction has the form C; A C2 (pronounced “C and C2”), and it is 
satisfied if and only if both C, and C4 are satisfied. Just as in ordinary logic, 
conjunction of constraints is associative and commutative. 


Not every judgment requires a constraint, so to keep the math and the code uni- 
form, such a judgment uses a third form of constraint: 


* The trivial constraint has the form T, and it is always considered satisfied. 
The trivial constraint is a left and right identity of \. The constraint may be 
pronounced “trivial” or “true.” 


Formally, constraints are described by this grammar: 


Cust ~12|C, AC, | T. 


If the type system derives C’, I’ e : 7, the constraint captures conditions that 
are sufficient to ensure that term e has type rT. And if constraint C is satisfied, then 
erasing constraints produces a derivation of | e : 7 that is valid in the original, 
nondeterministic type system. Operationally, constraint C’, like type 7, is an output 
from the type checker; the inputs are term e and environment I’. 

Using constraints, we can write a deterministic IF rule. The rule not only pro- 
duces new constraints 7; ~bool and T2~73; it also remembers old constraints used 
to give types to the subexpressions €1, €2, and e3. “Old” constraints propagate from 
the premises of a rule to the conclusion. 


Ci,T re, :% C2,T - e2 : T2 C3,0 F e3 : 73 
Ci A C2 A C3 A 71 ~ bool A 72 ~ 73, | IF(E1, €2, €3) : T2 


(IF) 


The conclusion of this rule conjoins three old constraints with two new simple 
equality constraints. For the IF expression to have a type, all the constraints needed 
to give types to €1, €2, and e3 must be satisfied. And so must constraints T; ~ bool 
and T2 ~ 73. If all the constraints are satisfied, which implies that Tt, = bool and 
T2 = 73, then the rule is equivalent to the original IF rule. 

Constraints require much less bookkeeping than do the substitutions in Sec- 
tion 7.5.1, but a typing judgment that describes lists of expressions and types is 
still worth defining. Judgment C,I F e€1,...,€n : T1,.--,7n expresses the ef- 
fects of n separate judgments, where C' is the conjunction of the constraints of the 
individual judgments: 


CTF e.:% see Caley t ty 


. TYPESOF 
Cr A-++ACy, TF e1,...,€n 2 T15-++57m ( 

This judgment can help simplify some rules, like the IF rule: 
CLT F e1, €2, €3 : T1, 72,73 (tr) 


CAT ~ bool A 72 ~ 73,0 | IF(e1, €2, €3) : Te 


The same judgment is used in the application rule, but the application rule also 
does something new. In an application, the function must have an arrow type, so 
if an expression e of type 7 appears in the function position, 7 must be an arrow 
type. But what arrow type? The argumenttypes are the types 71,..., Tn of e’s actual 
parameters, but what isthe result type? Because 7 might itself be a type variable, we 
can’t always know. So to stand in for the result type, the type checker uses a fresh 
type variable a, whose ultimate identity will be determined by a new constraint. 
The new constraint says that type 7 must be equal to 7] x +--+ X Tn, 4 a: 


CoP e pO 1 pct hey STMT ee fT ais fresh 
CAF X+++X Tm a,b APPLY(e,€1,...,€n) 1 Q 


(APPLY) 


Again, if the constraints are satisfied, the rule is equivalent to the original. 
These rules are enough to build an example derivation. The example uses a 
type environment I that contains these bindings: 


T= {+:V.int x int > int, cons : Va.a x alist > alist}. 


This I has no free type variables. Derivation of a type for (+ 1 2) looks roughly like 
this, where 19 is a fresh type variable: 


T,[Tb +: int x int > int TT, 1: int T,CF2:int 
TATATA int X int > int ~ int x int > ayo, F (+12) : ayo 
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Substituting int for a109 yields 


T,[b +: int x int > int ~int TT, 1: int T,[TF 2: int 
TATA T Aint x int > int ~ int x int > int, EF (+12): int 


All the constraints are satisfied, and if they are erased, what’s left is a derivation in 
the original, nondeterministic system. 


Converting nondeterministic rules to use constraints 


Every nondeterministic rule can be converted to a deterministic, constraint-based 
rule. Most conversions use just two techniques: 


+ Ifthe original rule uses the same type 7 in more than one place, give each use 
its own name (like 72 and 73), and introduce constraints forcing the names 
to be equal. 


¢ If the original rule uses 7 but does not specify what 7 is, represent T by a 
fresh type variable. 


The first technique is illustrated by the IF rule. The second technique can be illus- 
trated by converting the nondeterministic VAR rule to use explicit constraints. The 
nondeterministic rule says 


I(a)=o TKK 


VAR 

Tka:r ae) 

By definition, 7’ < o wheno = Vay,...,@n.7 and some (unknown) types are 

substituted for the a1,...,@,. For the unknown types, the rule uses fresh type 
variables a{,...,a’,. 

T(x) =Vay,..., Qn-T 
ai,...,a@/, are fresh and distinct 
: (VAR) 
TTF a: ((apaj)o-+-o(a,nH al))r 
In 7, each a; is replaced by the corresponding fresh aj, and a|,..., a), are even- 


tually constrained by the way x is used. For example, if x is cons and it occurs in 
the expression (cons 1 '()), the instance of cons uses a fresh type variable, which 
eventually should be constrained to be equal to int. The derivation looks roughly 
like this: 


I'(cons) = Va.a X alist + alist 


T,U F cons : aii X Qi1 list > ayi list 


T,TE1:int TCE 'QO: arg list 


TAT Aaa X Qi list > aii list ~int X aig list > ai3,0F (cons 1'()) : aig 


That big constraint is equivalent to this simpler constraint: 
Qyy~ int Aa, list ~ aj1g list A aq, list ~ aj3. 
Both constraints are solved by the substitution 
(Qi, + int) o (ajg +> int) o (a13 +> int list), 


and the type of (cons 1'()) isint list. 


Inferring polytypes for bound names 


In the examples above, each type variable is determined to be a completely known 
type, like int or int list. But when a polymorphic function or other value is de- 
fined, some free type variables will remain undetermined. The function being de- 
fined will be given a polymorphic type scheme that uses V with those type variables. 
For example, a function that makes a singleton list has a polymorphic type: 
423. (transcript 402) += <417a 425> 

-> (val singleton (lambda (x) (cons x '()))) 

Singleton : (forall ['a] ('a -> (list 'a))) 
Converting from a monotype 7 with free type variables to a type scheme o with an 
explicit forall is the most challenging part of type inference; this conversion is 
called generalization. 

Generalization is at its simplest in the rule for a VAL binding: 


Cy,TkFe:f 


OC is satisfied OC=T 
o = generalize(@r, ftv(I)) | 
(vAL(x,e),T) > T{ar ao} 


(VAL) 


The rule is interpreted operationally as follows: 
* Typecheck e in environment I’, getting back type 7 and constraint C. 


* Choose a substitution 6 such that OC is satisfied, making sure that 9 does 
not affect any free type variables of I’. (This step is called solving C; it is the 
subject of Section 7.5.3 below.) 


* Generalize the type 97 to form the type scheme a, which becomes the type 
of x ina new environment I'{x +> o}. 


Assuming there is a valid derivation of the first premise C, I’ F e : 7, the rule works 
because for any 6, 


- 6C,6T ' e: @7 is a derivable judgment. 
* Because 61 = I, the judgment 0C’,T' | e : 67 is also derivable. 


* Because OC is satisfied, | e : 07 is a derivable judgment in the original, 
nondeterministic system. 


- If the original system can derive type 67 for e, that type can safely be gener- 
alized. 


The VAL rule illustrates the key ideas underlying constraint-based inference of 
polymorphic type schemes: 


* Type inference requires a substitution 0 that solves a constraint C' but does 
not substitute for any free type variables of the environment I’. 


* Using substitution @ on a type 7 produces a type that can be generalized. 
For an example, in the definition 


(val singleton (lambda (x) (cons x '()))) 
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the body of the lambda is checked in type environment I” = T'{x +} V.ay4}, and 
the derivation of the type of the lambda looks something like this:* 


I’ (cons) = Va.a xX alist > alist I’ (x) =V.a14 


T,T- cons: ay5 X a15 list > aj5 list TI’ Fx: aya T,TE'Q : aye list 


Q15 X a15 list > aj15 list ~ a14 X aig list > a7, I’ (eons *% 10) 2 ai? 


Q15 X a15 list > ai5 list ~ ai4 X aig list > a17,I'- (lambda (x) (cons x '())) : a14 4 Q17 


The constraint can be simplified to 
Q15 ~ Ay4 \ A115 list ~ aig list A ay5 list ~ a17 
and then further simplified to 
C=ay53 ~ ay4 \ 15 ~ A16 A Q15 list ~ ay7. 


This constraint is solved by several substitutions; for example, it is solved by the 
substitution 0 = (a14 +4 a15) 0 (aig + G15) 0 (Q17 + Q15 list). The most in- 
teresting premises of the VAL are then 


C,T - (lambda (x) (cons x '())) : 7, 
T=Q14 > Q17, OT = Q15 — Q15 list, o= Va45-015 — Q15 list. 


Name singleton is therefore added to I with type scheme Vaj5.Q15 — Q15 list, 
which we prefer to write in canonical form as Va.a + a list. 


A term that has no type produces an unsolvable constraint 


In the method of explicit substitutions, when a term has no type, type inference 
fails because the type checker calls unify with two types that can’t be unified. In the 
method of explicit constraints, when a term has no type, type inference fails be- 
cause the type checker produces a constraint that can’t be solved. One such con- 
straint is produced by this example: 


(lambda (x) (cons x x)) 


Let’s assume that x is introduced to the environment with the monotype V.a13, that 
cons is instantiated with type 19 X Qig9 list — ajg9 list, and that the return type 
of the lambda is type variable a29. Then the system derives a judgment that looks 
roughly like this: 


Q19XQ19 list 4 ay9 list~aig XQ1g > A229, (lambda (x) (cons x x)) : Qig 4 20. 
The constraint can be simplified to 
Q19 ~ Aig \ Aig list ~ Aig A Aig list ~ ago. 


The third simple equality a19 list ~ aq can be satisfied by substituting a@19 list 
for a9. The first simple equality a19 ~ aig can be satisfied by substituting a19 
for aig or vice versa. So the full constraint is solvable if and only if the simple 
equality 

Qjig list ~ Qj9 


is solvable (or equivalently, if a1g list ~ a8 is solvable). But no possible substi- 


‘Just as in the nondeterministic system, the rule for lambda typechecks the body in an extended 
environment that binds the formal parameter x to a monotype. If you wonder why I don’t show you a 
rule for lambda, it’s because I want you to develop the rule yourself; see Exercise 8 on page 446. 


tution for a9 can make a9 list equal to a19.° And after putting the unsolvable 
constraint into canonical form, that’s what the interpreter reports: 
425. (transcript 402) += 1423 426> 


-> (val broken (lambda (x) (cons x x))) 
type error: cannot make 'a equal to (list 'a) 


A prequel to LETX forms: Adding constraints is OK 


What's left are the rules for LETX forms. These forms generalize the types of mul- 
tiple bound names, which gets complicated. To avoid that complexity, most pre- 
sentations of this theory work with a simplified “core calculus.” But if you’re build- 
ing an interpreter that infers types, you don’t want some simplified core calculus; 
you want to infer types for code you actually write. To do it soundly, you'll need a 
rule that allows us to add a constraint: 


C05 6: % Chas a solution 
CAC,,0F eG : 7; 


(OVERCONSTRAINED) 


The idea is that although the constraint C;; is sufficient to give e; a type, we may add 
another constraint C’, provided that C' has a solution. To prove this rule sound, 
we appeal to the substitution 6 that solves C: if 0 is applied to the valid derivation 
associated with the judgment C;,,I e; : 7;, the result is another valid derivation. 


Generalization in Milner’s LET binding 


The most difficult part of constraint-based type inference is its generalization at a 
LET binding. In (let ([2 1 €1]) ---), the key elements are the type of e; and the 
type scheme bound to x,. These types are determined by this sequence of opera- 
tions: 


* The type checker recursively checks e; in type environment I’, getting back 
a type 7, and a constraint C’. 


* The type checker asks a constraint solver to solve C’, getting substitution 0. 


* Constraint C affects type variables that are free in 7 or in I’. The type vari- 
ables that are free in 7 can be eliminated by applying 0 to 7. But free type 
variables of I’ can’t be substituted for; that would be unsound. Instead, the 
effect of 0 on those type variables is captured in a new constraint C’. Con- 
straint C’ is built by applying 6 to the free type variables of T: 


CS /\fa~ da | a € domén ftv(T)}. 


The notation /\{...} says to form a single constraint by conjoining the con- 
straints in the set. If the set is empty, \@ = T. 


* Type scheme o} is computed in two steps: First, apply @ to 71, getting the 
type of e; as refined by constraint C’. Second, generalize 07, by quantifying 
over all of the type variables that are mentioned neither in T' nor in C’. 


5For a proof, consider the number of times that list appears on each side. No matter what you 
substitute for aig, there will always be one more list constructor on the left than on the right, so the 
two sides can never be equal. 
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These operations can be formalized as an incomplete rule, which puts the type 
scheme of x into I”: 


CL,TFe.:% 
OC is satisfied @ is idempotent 
C’ = \{a~ da | a € dom én ftv(T)} 
o1 = generalize(07, ftv(T) U ftv(C’)) 


Y=T{apro 
ML and type {1 (INCOMPLETE SIMPLE LET) 
inference oe 
he Because @ is used to form both C’ and oj, it can eventually be used twice, so for 


soundness, it must be idempotent (sidebar on the facing page). 

To complete the rule, tell the type checker to use new environment I” to infer 
the type of the body of the let. Extending the incomplete rule to work with an 
arbitrary number of bound variables 7 1,..., x,, results in this rule: 


GAT Peis. 2.5 Cp ET eos pT 
OC’ is satisfied 6 is idempotent 
C’ = \{a~ a] a €domén ftv(T)} 
oj; = generalize(67;,ftv([) Uftv(C’)), l<i<n 
Cy, TP {a1 o1,.--,In to on}Fe:t 
C’ A Cy, TF LET((a1, €1,---,;2n,€n), €) 2 T 


(LET) 


In LETREC, the e,’s are checked in an extended environment where each 1; is 
bound to a fresh type variable a;, and before generalization, each type 7; is con- 
strained to be equal to the corresponding a. The rest is the same. 


€1,---,€n are all LAMBDA expressions 
IY =T{a1 a,...,£2n ++ An}, where all a;’s are distinct and fresh 
Gg l Peis fee cep P teasing 


C=CrLATM1 ~a1A++:ATr~ On 
OC is satisfied is idempotent 
C' = \{a~ da|a€ domén ftv(T)} 
oj = generalize(07;,ftv([) Uftv(C’)), lL<i<n 
Cy, T{ay + 01,.-.,%n OH onpbe:r 
C’ A\ Cy, TF LETREC((21, €1,---,2n,€n),€) 2 T 


(LETREC) 
As an example of generalization in LET, I present a function that builds nested 
singleton lists: 
426. (transcript 402) += 1425 
-> (val ss (lambda (y) 
(let ([single (lambda (x) (cons x '()))]) 
(single (single y))))) 
ss : (forall ['a] ('a -> (list (list 'a)))) 
The whole derivation won't fit on a page, so let’s look at pieces. Start by assuming 
that the body of the outer lambda is typechecked in an environment 


T = {cons : Va.a X alist > alist,y : ago}. 


In a similar environment, the singleton example on page 423 shows a derivation 
for the lambda, so if C = a22 X G22 list 4 @o2 list ~ Q21 X A293 list > aga, 
we can take it for granted that 


C,T - (lambda (x) (cons x '())) : @21 4 Qaq 


Soundness of generalization with constraints 


Informally, generalization uses constraints as follows: 


* The type being generalized is computed by the judgment C,IF e; : 74. 
For example, 
a~int, TF (+#x1): a, 


where [’ = {x : a}. Even though the type of (+ x 1) has a type variable, 
it can’t be generalized: a has to be int. 
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Solving constraint C' produces substitution 6 = (a@ +4 int). The type 71 
is an output, so int can be substituted for a there, getting type 97, = int. 
But I is an input, so there’s no way to substitute there: the constraint has 
to be retained. 


In the general case, the type checker takes the constraint C' and its solu- 
tion 0, and it splits @ into two parts, so that 6 = 0, o 0, where 

-Q= 9| som @\fev(L) is the local part; it substitutes for type variables 
that are mentioned in C (and possibly in 7) but never in I’. Substi- 
tution 6; can be applied to 7 and then thrown away. 


- = 0| ftv(P) is the global part; it substitutes for type variables that 
are mentioned in I’. It can be applied to 7 but not to I’. Substitu- 
tion 9, can't be thrown away, so it is converted to constraint C’. 


* Because 0; is computed by generalizing 071, none of the variables in 
dom 6 is generalized, and @ is idempotent, 90, = 0}. 


From a valid derivation of 8C’, @T' + e, : 801, the equalities above can be used 
to recover a valid derivation in the original, nondeterministic system. 


is derivable. The next part of the derivation uses an instance of the LET rule with 
these values for its metavariables: 


C= Q22 X A22 list + Qg2 list ~ aq] X A293 list > ao4 
T1 = 21 — A24 
6 = (21 1 22) © (23 + 22) O (24 +4 M22 list) 
A{}=T 
ftv(T) = {ao} 
O01 = generalize(ag2 + a22 list, ftv(T)) = Va22.a22 > a2 list. 


The body of the LET, (single (single x)), is checked in the extended envi- 
ronment [, = [{single : Vag2.a@22 —> Qg2 list}. Each instance of single cons 
gets its own type, and the typing derivation gets crowded. Abbreviating constraint 
Cinner = 25 > Qe5 list ~ a29 — 26, we have 


T'e(single) = Va22.022 > a22 list Te(y) = V.a209 
Te(single) = Va22.a22 > a2 list T, Tet single : ag5 + ag5 list T,Per y: a20 
T,Te b single : a27 > a27 list Cinner, Ve / (single y) : a26 


a27 > a7 list ~ a26 > 28g A Cinner, Ce F (single (single y)) : a2g 


The type of the outer lambda is therefore a29 — Q2g, with constraint C’ A Cb, 
which is 


TA Q27 —> Ao7 list ~ Q2g — Q2g A\ A25 > Ag5 list ~ G29 > Ag¢6. 
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This constraint is equivalent to 
Q27 ~ A296 \ Ag7 list ~ Ag A Qe5 ~ Gag A M25 list ~ O96, 
which is solved by the substitution 
(Q27 + Aa0 List) o (agg +4 27 list) o (a5 +4 29) O (26 +4 Q25 list), 
which is equivalent to the substitution 
(Q27 + A209 list) o (agg ++ Ago list list) o (a25 4 A209) o (2g + 9 list), 


The type of the outer lambda is therefore a29 —> M9 list list, and at the VAL 
binding, this type is generalized to the type scheme Va29.@29 M0 list list. 


7.5.3 Solving constraints 


As shown by the examples above, the method of explicit constraints reduces type 
inference to a constraint-solving problem. Solving a constraint tells us what, if any- 
thing, to substitute for each type variable. The substitutions are used to finalize 
types at LET and VAL, where potentially polymorphic names are bound. The de- 
tails are all here, and you can use them to build your own constraint solver. 

A constraint is satisfied if types that are supposed to be equal actually are equal: 


T| =T2 C is satisfied C4 is satisfied 
T1 ~ T2 is satisfied C A C4 is satisfied T is satisfied 


Constraints, like types, can be substituted in, as specified by these laws: 
O(71 ~ T2) = O71 ~ O72, O(C1 A C2) = 0C1 A OC 2, 6T = T. 


The laws are implemented in chunk 436c, and the constraints’ ML representation 
is shown in chunk 436a. 

A constraint C’ is solved by finding a substitution 6 such that 9C is satisfied; 
we say that 6 solves C’. Not all constraints can be solved; for example, the constraint 
int ~ bool is not solved by any 6, and neither is a ~ a list. 

If a constraint can be solved, a solution can be found by an algorithm called 
a constraint solver. A constraint solver has the same power as the unify function 
(page 417). Given a solver, any two types 7; and 72 can be unified by a substitution 
that solves the constraint 7; ~ T2. And given unify, any constraint can be solved by 
a substitution that unifies two types constructed from the constraint (Exercise 20). 

Our constraint solver accumulates substitutions; this strategy works because 
once a constraint is satisfied, it remains satisfied even after further substitutions 
(Exercise 4). That is, if OC is satisfied, and if 6’ is another substitution, then 6’ (@C) 
is also satisfied. Equivalently, (0’ o @)C is satisfied. 


Cases for constraint solving 


A constraint solver is given a constraint C’ and returns a substitution 0 such that 
OC is satisfied. The solver need consider only three cases: 


* Cis the trivial constraint T, in which case 0; solves C’. 


* Cis the conjunction C) A C2, in which case both sub-constraints C, and C2 
must be solved. 


+ Cis a simple equality constraint of the form 71 ~ 72. 


Both conjunctions and simple equality constraints require attention to detail. 


Sadly, a conjunction C) \ C2 can’t be solved by first solving C1, then solving C2, 
then composing the solutions. This technique works only some of the time, as ex- 
pressed by the following rule: 


6, C;, is satisfied OC is satisfied 
(05 0 0,)(Cy A Cz) may or may not be satisfied 


(UNSOLVEDCONJUNCTION) 


Even when 6; solves C'; and ip solves C2, neither 05 o 6; nor 6; 0 65 is guaranteed 
to solve C; A C2. The substitution #2 wears a tilde because I’m going to treat it as 
the bad guy; looking at 02 0 6,, here’s what goes wrong: 


* We want (02 0 0,)(C A C2) to be satisfied. According the rule for satisfying 
conjunctions, this means both (02 0 6, )C) and (62 0 6;)C> must be satisfied. 


+ By the assumption that 6; solves Ch, 6, C, is satisfied. And because satisfac- 
tion is preserved by substitution, (02 o 0 )C{ is satisfied. So far, so good. 


* Constraint (6. 061)C2 = A> (6, C2) must also be satisfied. But unfortunately, 
although 62 solves C2, that doesn’t guarantee that it also solves 0,C9. 


This line of thinking can be carried further with a proof and some examples (Exer- 
cises 12 and 16). 

The unreliable technique fails because in the last step, the constraint that must 
be solved is not C9; itis 0; C2. This observation leads to a reliable technique, which 
is expressed by the following rule: 


6, C is satisfied 62(0, C2) is satisfied 
(82 0 01)(Cy A C2) is satisfied 


(SOLVEDCONJUNCTION) 


Substitution 62, which may be different from bs, does what we need (Exercise 13). 
The rule is interpreted operationally as follows: To solve a conjunction, call the 
solver recursively, apply 6; to Cy, call the solver recursively again, and return the 
composition of the two substitutions. 

To remember the rule and the algorithm, I think like this: if 0; solves C1, then 
0, represents the assumptions that I have to make for C} to have a solution. If those 
assumptions are to hold everywhere, then they must be accounted for when I look 
at C2. And they are accounted for by applying 61. 


Solving simple equality constraints 


In addition to conjunctions, a constraint solver must also solve simple equality con- 
straints of the form 7, ~ T2. Because each type may be formed in three different 
ways, a simple equality constraint is formed in one of nine different ways. Nine 
cases is a lot, but the code can be cut down by clever use of ML pattern matching. 
And in every case, the goal is the same: find a 6 such that 67, = 672. Let’s tackle 
the most tricky case first, the easy cases next, and the most involved case last. 

The tricky case is one in which the left-hand side is a type variable, giving 
the constraint the form a ~ 72. This constraint can be solved by the substitution 
(@ ++ 72), but only in some cases: 


+ If 72 does not mention a, then (@ +> 72)T2 = 72, and also (@ +4 72)a = 72. 
Solved! 


* If 7» is equal to a, then (a ++ a) is the identity substitution 67. Also solved. 


* If T. mentions a but is not equal to a—for example, suppose T2 is a list—then 
the constraint @ ~ 72 cannot be solved (Exercise 15). 


Type T2 mentions a if and only if a occurs free in T2. This property has to be tested; 
the test is called the occurs check. 
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Performance of type inference 


Nano-ML’s type inference is designed for clarity, not performance. If you write 
a definition that includes hundreds of function applications, you get hundreds 
of constraints. Solving them may result in hundreds of thousands of calls to 
tysubst, which in turn may mean tens of millions of string comparisons in 
find—the total cost of finding out what to substitute for each type variable is 
quadratic in the number of variables, and type inference can take hours. 


A production compiler has no such issues. Production code uses efficient rep- 
resentations of names and environments, and substitution is implemented in 
constant time by updating the contents of a mutable reference cell, much as in 
a union-find algorithm. 


To avoid nano-ML’s performance issues, avoid deeply nested calls. For example, 
if you want to build a list of a thousand elements, try something like this: 
(let* 
(Ins '()] 
[ns (cons 1000 ns)] 
[ns (cons 999 ns)] 


[ns (cons 1 ns)]) 
ns) 


At every binding the constraint solver is called with a small constraint involving 
just a few type variables, so type inference is quick. 


Alternatively, type inference of large lists can be made efficient by better lan- 
guage design: a list constructor builds a list of any length using just a single type 
variable, which represents the element type of the list (Exercise 22). 


Suppose the left-hand side of the constraint is not a type variable, but the right- 
hand side is. That is, the constraint has the form 7, ~ a. This constraint has the 
same solutions as a~7;; the solver can swap the two sides and call itself recursively. 

If neither side is a type variable, then each side must be a type constructor or 
a type application (TYCON or CONAPP). If the left is a constructor and the right is an 
application, or vice versa, the constraint can’t be solved. And if both sides are type 
constructors, substitution leaves them unchanged, soa constraint of the form p~ ju 
is solved by the identity substitution, and a constraint of the form jy ~ yp’, where 
p. # pw’, cannot be solved. 

The most complicated case is a constraint in which both sides are constructor 
applications. Because every substitution must preserve the structure of a construc- 
tor application (see the substitution laws on page 409), such a constraint can be 
broken down into a conjunction of smaller constraints: 


Or~t' AM ~T{A+++AT~ T,) is satisfied 
O(CONAPP(T, (71,---,Tn)) ~ CONAPP(T’, (T],...,7/,))) is satisfied 
(SOLVECONAPPCONAPP) 
This rule is also sound (Exercise 14). Operationally, the solver is given the con- 
straint on the bottom. It then builds the constraint on the top, on which it calls 
itself recursively. The recursion terminates because the number of CONAPPs de- 


creases. 


An example of constraint solving 


Using the ideas above, let’s solve the constraint from (cons 1 '()), 
TA (T A Q11 X Qy, list > aq, list ~ int X ay2 list > 013). (7.1) 


This constraint is big enough to be interesting, but for a complete, formal deriva- 
tion, it’s a little too big. So let’s solve it informally. 

The constraint is a conjunction, so we first solve the left conjunct, which is T. 
This conjunct is solved by the identity substitution 0;, which we then apply to the 
right conjunct 


TA Q11 X Qy, list > ay, list ~ int X aj2 list > aj3. (7.2) 


The identity substitution leaves this conjunct unchanged, and we continue solving 
recursively. The same steps lead us to solve 


Q41 X ay, list > ay, list ~ int X aj2 list > aj3. (7.3) 


This simple equality constraint has CONAPP (with the — constructor) on both sides. 
We use the SOLVECONAPPCONAPP rule to convert this constraint to 


(> ~ >) A (au X ai, list ~ int X ajg list A ay, list ~ Q13). (7.4) 


The left conjunct, (+ ~—), has two equal type constructors and so is solved by 67, 
which, when applied to the right conjunct, leaves it unchanged. So we solve 


Q41 X Qy, list ~ int X ay2 list Aa, list ~ aj3. (7.5) 
The next step is to solve the left conjunct 
Q4, X ay, list ~ int X aj2 list, (7.6) 


which requires another application of the SOLVECONAPPCONAP?P rule, asking us to 
solve 
(x ~ x) Aa ~ int A ay, list ~ ay list. (7.7) 


We must next solve 
a1. ~ int A ay, list ~ aj list, (7.8) 
and we begin with its left conjunct 
Qi, ~ int. (7.9) 


Finally we have a case with a type variable on the left, and constraint 7.9 is solved 
by 6; = a1, + int. We then apply 6; to the constraint a1; list ~ aj list, 
yielding 
int list ~ aj2 list. (7.10) 
Let’s not go through all the steps; constraint 7.10 is solved by 02 = ay2 +> int. 
Constraints 7.6, 7.7, and 7.8 are therefore solved by the composition of #; and 62, 
which is 62 0 6; = (aig +> int oa + int). 
Now we can return to constraint 7.5. We apply 62 o 6; to the right conjunct 
Q11 list ~ a13, yielding 
int list ~ aj3, (7.11) 


which is solved by substitution 63 = a 3 +> int list. Constraint 7.5 is therefore 
solved by substitution 03 0 09 0 61, which is 


6 = 0300206; = 40434 int listo ajg' intoay,, 4 int. 


Substitution 0 also solves constraints 7.1 to 7.4. 
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Table 7.3: Correspondence between nano-ML’s type system and code 


Type system Concept Interpreter 
d Definition def (page 405) 
ae and type e Expression exp (page 404) 
inference x Variable name (page 303) 
432 a Type variable tyvar (page 408) 
ig Type ty (page 408) 
0, Va.T Type scheme type_scheme (page 408) 
T=T' Type equivalence eqType(T, 7’) (page 412) 
T Typeenvironment type_env (page 435) 
I(a) =o Type lookup findtyscheme(x, I’) = o (page 435) 
T{a+4 o} Type binding bindtyscheme(x, 0, I’) (page 435) 
C Constraint con (page 436) 
T1 ~ T2 Equality constraint 71 ~ T2 (page 436) 
Ci A C2 Conjunction C1 /\ C2 (page 436) 
T Trivial constraint TRIVIAL (page 436) 
AZO; Conjunction conjoinConstraints [Ci,...,C)] 
(page 436) 
ftv(7) Free type variables freetyvars 7 (page 433) 
ftv(T) Free type variables freetyvarsGamma I’ (page 435) 
ftv(C) Free type variables freetyvarsConstraint C (page 436) 
Ci,Tbe:r Type inference typeof(e, I) = (7,C), also 
ty e = (7, C) (page 437; some parts left 
as an exercise) 
(d,T) +I’ Type inference typdef(d, [) = CI’, s) (page 439) 
0 A substitution subst (page 410) 
Or Identity substitution idsubst (page 411) 
[a> T] Substitution fora a |--> T (page 411) 
Or Substitution tysubst 6 7 (page 410) 
da Substitution varsubst 6 a (page 410) 
dC Substitution consubst 6 C (page 436) 
02064 Composition compose (page 411) 
dom 0 Domain dom (page 411) 
6C=T Constraint solving 6 = solve C (left as an exercise, 
page 437) 
C=T Solved constraint isSolved C (page 437) 
Va.T becomes et : F , 
nee Instantiation instantiate(Va.7T, [7']) (page 411) 
int, bool,... Base types inttype, booltype, ... (page 412) 


T X+++X Tn — T Function type 


funtype([71,---, 71, 7) (page 412) 


7.6 THE INTERPRETER 


In most respects, the interpreter for nano-ML is the interpreter for Scheme (Chap- 
ter 5), plus type inference. Significant parts of type inference don’t appear here, 
however, because they are meant to be exercises. 


7.6.1 Functions on types and type schemes 


This section defines functions that are used throughout type inference. 

Function freetyvars returns a set containing the free type variables of a type. 
For readability, it builds the set so type variables appear in the order of their first 
appearance in the type, when reading from left to right. 


433a. (sets of free type variables in Hindley-Milner types 433a)= (S420a) 
fun freetyvars t = freetyvars : ty -> name set 
let fun f (TYVAR v, ftvs) = insert (v, ftvs) 
| f (TYCON _, ftvs) = ftvs 


| f CCONAPP (ty, tys), ftvs) = foldl f (f (ty, ftvs)) tys 
in reverse (f (t, emptyset)) 
end 


Canonical type schemes 


Type variables like 't136 are not suitable for use in error messages. A type scheme 
like (forall ['t136] ((list 't136) -> int)) is unpleasant to look at, and it is 
equivalent to the more readable (forall ['a] ((list 'a) -> int)) When a type 
variable is V-bound, its name is irrelevant, so function canonicalize renames 
bound type variables using names 'a, 'b, and soon. 

433b. (shared utility functions on Hindley-Milner types 410a) += (S420a) <1412a 434aD 


Ccanonicalize : 


type_scheme -> type_scheme 
int * name list -> name list 


newBoundVars : 


fun canonicalize (FORALL (bound, ty)) = 
let fun canonicalTyvarName n = 
if n < 26 then "'" A str (chr (ord #"a" + n)) 
else "'v" A intString (n - 25) 
val free = diff (freetyvars ty, bound) 
fun unusedIndex n = 
if member (canonicalTyvarName n) free then unusedIndex (n+1) else n 


fun newBoundVars (index, []) a 
| newBoundVars (index, oldvar :: oldvars) = 
let val n = unusedIndex index 
in canonicalTyvarName n :: newBoundVars (n+1, oldvars) 
end 
val newBound = newBoundVars (0, bound) 
in FORALL (newBound, 
tysubst (mkEnv (bound, map TYVAR newBound)) ty) 


end 


Internal function unusedIndex finds a name for a single bound type variable; it en- 
sures that the name is not the name of any free type variable. 


Fresh type variables 


A type variable that does not appear in any type environment or substitution is 
called fresh. When a function is introduced, fresh type variables are used as the 
(unknown) types of its arguments. When a polytype is instantiated, fresh type 
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variables are used as the unknown types that are substituted for its bound type 
variables. And when a function is applied, a fresh type variable is used as its (un- 
known) result type. 

Fresh type variables are created by the freshtyvar function. The function uses 
a private mutable counter to supply an arbitrary number of type variables of the 
form tn. Because a nano-ML expression or definition never contains any explicit 
type variables, the names don’t collide with other names. 


434a. (shared utility functions on Hindley-Milner types 410a) += (S420a) <433b 434bp> 
local freshtyvar : 'a -> ty 
val n = ref 1 
in 
fun freshtyvar _ = TYVAR ("'t" A intString (!n) before n := !n + 1) 
end 


Generalization and instantiation 


Calling generalize(r, A) generalizes type 7 to a type scheme by closing over type 
variables not in A. It also puts the type scheme into canonical form. 


434b. (shared utility functions on Hindley-Milner types 410a) += (S420a) <1434a 434c> 


generalize : ty * name set -> type_scheme 


fun generalize (tau, tyvars) = 
Ccanonicalize (FORALL (diff (freetyvars tau, tyvars), tau)) 


The dual function, instantiate, is defined in chunk 411b. It requires a list of 
types with which to instantiate. That list is often a list of fresh type variables, as 
provided by function freshInstance. 
434c. (shared utility functions on Hindley-Milner types 410a) += (S420a) <434b 


freshInstance : type_scheme -> ty 


fun freshInstance (FORALL (bound, tau)) = 
instantiate (FORALL (bound, tau), map freshtyvar bound) 


7.6.2 Type environments 


Function generalize is called with the free type variables of some type environ- 
ment. And a type environment contains the type of every defined name, so it can 
get big. To reduce the cost of searching a large environment for free type variables, 
a type environment is represented in a way that enables the type checker to find 
free type variables in constant time. 

A representation of type environments must support these functions: 


* Function bindtyscheme adds a binding x : o to the environment I’. It is used 
to implement the LAMBDA rule and the various LET rules. 


* Function findtyscheme looks up a variable «x to find o such that (x) = o. 
It is used to implement the VaR rule. 


* Function freetyvarsGamma finds the type variables free in I’, i.e., the type 
variables free in any 0 in I’. Itis used to get a set of free type variables to use 
in generalize; when a type scheme is assigned to a let-bound variable, only 
those type variables not free in may be V-bound. 


If freetyvarsGamma used a representation of type type_scheme env, it would visit 
every type scheme in every binding in the environment. Because most bindings 
contribute no free type variables, most visits would be unnecessary. Instead, all 


Why generalize and instantiate? 


We use quantified types (i.e., type schemes) so we can instantiate them when we 
look them up in an environment. Instantiation gives us the full effect of poly- 
morphism. Without instantiation, we wouldn't be able to type such ML terms as 
(1::nil, true::nil). Suppose we had an environment I with only types, not 
type schemes: 


T = {1: int, true : bool, nil : a list,:::a@ x alist > alist}. 


When typechecking 1::nil, we would get the constraint a ~ int. And when 
typechecking true: :nil, we would get the constraint a ~ bool. But the con- 
junction a ~ int A a~ bool has no solution, and type checking would fail. 


Instead, we use freshInstance to make sure that every use of a polymorphic 
value (here : : and nil) has a type different from any other instance. In order to 
make that work, the environment has to contain polytypes: 


T = {1: Vint, true : V.bool, nil : Va.a@list,::: Va.a@xalist > alist}. 


Now, we can imagine our sample term like this, writing :: as a prefix operator 

so as to show the types: 

(op :: : 't1l21 * 't121 list -> 't1l21 list (1 : int, nil: 
op :: : 't123 * 't123 list -> 't123 list (true : 


'tlee list), 


bool, nil : 't124 list)) 


The constraint 't121 ~ int A int ~ 't122 A 't123 ~ bool A bool ~ 't124 
does have a solution, and the whole term has the type int list * bool list, as 
desired. 


functions use a representation that includes a cache of the type environment’s free 
type variables. 


435a. (specialized environments for type schemes 435a) = 
type type_env = type_scheme env * name set 


(S420a) 435b > 


An empty type environment binds no variables and has an empty cache. Look- 
ing up a type scheme ignores the cache. 


435b. (specialized environments for type schemes 435a) += (S420a) <1435a 435c> 


emptyTypeEnv : type_env 
findtyscheme : name * type_env -> type_scheme 


val emptyTypeEnv = 
(emptyEnv, emptyset) 
fun findtyscheme (x, (Gamma, free)) = find (x, Gamma) 


Adding a new binding also adds to the cache. The new cache is the union of the 
existing cache with the free type variables of the new type scheme o. 
435c. (specialized environments for type schemes 435a) += (S420a) <435b 435d> 


name * type_scheme * type_env -> type_env 


bindtyscheme : 


fun bindtyscheme (x, sigma as FORALL (bound, tau), (Gamma, free)) = 
(bind (x, sigma, Gamma), union (diff (freetyvars tau, bound), free)) 


Free type variables are found in the cache in constant time. 


435d. (specialized environments for type schemes 435a) += 
fun freetyvarsGamma (_, free) = free 


(S420a) <3435c¢ 


freetyvarsGamma : type_env -> name set 
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7.6.3 Constraints and constraint solving 


In the interpreter, constraints are represented in a way that resembles the math: 
the ~ operator is »; the / operator is /\; and the T constraint is TRIVIAL. 
436a. (representation of type constraints 436a)= (S420b) 
datatype con =~ of ty * ty 
| /\ of con * con 
| TRIVIAL 
infix 4% 
infix 3 /\ 
(The name ~ normally stands for ML’s negation function. An unqualified ~ is rede- 
fined by this datatype definition, but negation can still be referred to by its quali- 
fied name Int.».) 


Utility functions on constraints 


Many of the utility functions defined on types have counterparts on constraints. 
For example, we can find free type variables in a constraint, and we can substitute 
for free type variables. 
436b. (utility functions on type constraints 436b) = (S420b) 436c > 
fun freetyvarsConstraint (t ~ t') = union (freetyvars t, freetyvars t') 
| freetyvarsConstraint (c /\ c') = union (freetyvarsConstraint c, 
freetyvarsConstraint c') 
| freetyvarsConstraint TRIVIAL = emptyset 


A substitution is applied to a constraint using the following laws: 
O(71 ~ Ta) = 07, ~ O72, A(C, A C2) = OC; A 6Co, OT =T. 


The code resembles the code for tysubst in chunk 410c. 
436c. (utility functions on type constraints 436b) += (S420b) <436b 436d> 


consubst : subst -> con -> con 


fun consubst theta = 
let fun subst (taul ~ tau2) tysubst theta taul ~ tysubst theta tau2 
| subst (cl /\ ce) subst c1 /\ subst c2 
| subst TRIVIAL = TRIVIAL 
in subst 


end 
The A{---} notation is implemented by ML function conjoinConstraints. 


To preserve the number and order of sub-constraints, it avoids using foldl or 
foldr. 


436d. (utility functions on type constraints 436b) += (S420b) <1436c 437¢> 
fun conjoinConstraints [] = TRIVIAL |conjoinConstraints : con list -> con 
| conjoinConstraints [c] ="¢ 


| conjoinConstraints (c::cs) = c /\ conjoinConstraints cs 


Two more utility functions are defined in Appendix R: constraintString can 
be used to print constraints, and untriviate, whose type is con -> con, removes 
trivial conjuncts from a constraint. 


Constraint solving 


If type inference is given an ill-typed program, it produces an unsolvable con- 
straint. Examples of unsolvable constraints include int ~ bool anda list ~ a. 
Given an unsolvable constraint, the type checker should issue a readable error 
message, not one full of machine-generated type variables. To do so, function 


unsatisfiableEquality takes the pair of types that can’t be made equal, puts the 
pair into canonical form, and raises the TypeError exception. 
437a. (constraint solving 437a) = (S420b) 
fun unsatisfiableEquality (t1, te) = 
let val ti_arrow_t2 = funtype ([t1], t2) 
val FORALL (_, canonical) = 
Canonicalize (FORALL (freetyvars ti_arrow_t2, t1l_arrow_t2)) 
in case asFuntype canonical 
of SOME ([t1i'], te') => 
raise TypeError ("cannot make " A typeString ti' A 
"equal to " A typeString te') 
| _ => raise InternalError "failed to synthesize canonical type" 
end 


The mechanism is a little weird. To make a single type out of 7, and 79, so their 
variables can be canonicalized together, I make the type T; —> 72. What’s weird is 
that there’s no function—it’s just a device to make one type out of two. When I get 
the canonical version, I take it apart to get back canonical types t1' and t2'. 
I don’t provide a solver; I hope you will implement one. 
437b. (constraint solving [prototype] 437b)= 
fun solve c = raise LeftAsExercise "solve" solve : 


con -> subst 


For debugging, it can be useful to see if a substitution solves a constraint. 


(S420b) 3436d 
con -> bool 


437c. (utility functions on type constraints 436b) += 


isSolved : 
solves : subst * con -> bool 


fun isSolved TRIVIAL = true 
| isSolved (tau ~ tau') = eqType (tau,tau') 
| isSolved (c /\ c') = isSolved c andalso isSolved c' 
fun solves (theta, c) = isSolved (consubst theta c) 


7.6.4 Type inference 


Type inference builds on constraint solving. It comprises two functions: typeof, 
which implements the typing rules for expressions, and typdef, which implements 
the rules for definitions. 


Type inference for expressions 


Given an expression e and type environment I’, function typeof (e, I’) returns a 
pair (7,C) such that C,[. + e : 7. It uses internal functions typesof, literal, 
and ty. 


437d. (definitions of typeof and typdef for nano-ML and ML 437d)= (S420b) 439a > 


typeof : exp * type_env -> ty * con 
typesof : exp list * type_env -> ty list * con 
literal : value -> ty * con 

fun typeof (e, Gamma) = ty : exp —-> ty * con 


let (shared definition of typesof, to infer the types of a list of expressions 438a) 
(function literal, to infer the type of a literal constant (left as an exercise)) 
(function ty, to infer the type of a nano-ML expression, given Gamma 438c) 
in tye 
end 
Calling typesof((e1,...,€n), I’) returns ((71,..., 7), C) such that for every 7 
from 1ton, C,I'F e; : 7;. The base case is trivial; the inductive case uses this rule 
from Section 7.5.2: 


Ci,T bre, :% CAs leet 
Ci A---ACy, Tk e4,... 


: (TYPESOF) 
9€n > T1,-++5Tn 
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TypeError §213d 
typesof 438a 
typeString S431b 
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union $217b 


type value 405b 


Both cases are implemented by function typesof. 


438a. (shared definition of typesof, to infer the types of a list of expressions 438a) = (437d) 
fun typesof ([], Gamma) = ([], TRIVIAL) 
| typesof (e::es, Gamma) = 
let val (tau, c) = typeof (e, Gamma) 
val (taus, c') = typesof (es, Gamma) 


in (tau :: taus, c /\ c') 
end 
ML and type : : ; eens ‘ 
s ae To infer the type of a literal value, we call literal, which is left as Exercise 19. 
438b. (function literal, to infer the type of a literal constant [prototype] 438b)= 
438 fun literal _ = raise LeftAsExercise "literal" 


438c. (function ty, to infer the type of a nano-ML expression, given Gamma 438c) = (437d) 
fun ty (LITERAL n) = literal n 
(more alternatives for ty 438d) 


To infer the type of a variable, we use fresh type variables to create a most gen- 
eral instance of the variable’s type scheme in I’. No constraint is needed. 
438d. (more alternatives for ty 438d)= (438c) 438e > 
| ty (VAR x) = (freshInstance (findtyscheme (x, Gamma)), TRIVIAL) 


To infer the type of a function application, we need a rule that uses constraints. 
By rewriting the nondeterministic rule as described in Section 7.5.2, we get this 
rule: 


CLT F €,e€1,...,€n :7,71,---,T ais fresh 
CAF~T X+++X Tm a,b APPLY(e,€1,...,€n) 2 a 


(APPLY) 


This rule is implemented by letting funty stand for 7, actualtypes stand for 
T1,;--+,Tn, and rettype stand for a. The first premise is implemented by a call 
to typesof and the second by acall to freshtyvar. The constraint is formed just as 
specified in the rule. 
438e. (more alternatives for ty 438d) += (438c) <1438d 438f> 

| ty (APPLY (f, actuals)) = 
(case typesof (f :: actuals, Gamma) 
of ({], _) => raise InternalError "pattern match" 
| (funty :: actualtypes, c) => 
let val rettype = freshtyvar () 
in (rettype, c /\ (funty ~ funtype (actualtypes, rettype))) 
end) 


To infer the type of a LETSTAR form, we desugar it into nested LETs. 


438f. (more alternatives for ty 438d) += (438c) <438e 
| ty (LETX (LETSTAR, [], body)) = ty body 
| ty (LETX (LETSTAR, (b :: bs), body)) = 
ty (LETX (LET, [b], LETX (LETSTAR, bs, body))) 
Inference for the remaining expression forms is left as an exercise. 


438g. (more alternatives for ty [prototype] 438g) = 


| ty C(IFX (e1, e2, e3)) = raise LeftAsExercise "type for IFX" 

| ty (BEGIN es) = raise LeftAsExercise "type for BEGIN" 
| ty (LAMBDA (formals, body)) = raise LeftAsExercise "type for LAMBDA" 
| ty (LETX (LET, bs, body)) = raise LeftAsExercise "type for LET" 

| 


ty (LETX (LETREC, bs, body)) = raise LeftAsExercise "type for LETREC" 


Typing and type inference for definitions 


A definition extends the top-level type environment. Function typdef infers the 
type of the thing defined, generalizes it to a type scheme, and adds a binding to the 
environment. This step types the definition. Function typdef returns the new type 
environment, plus a string that describes the type scheme of the new binding. 


439a. (definitions of typeof and typdef for nano-ML and {tML 437d) += (S420b) <437d 


fun typdef (d, Gamma) = typdef : def * type_env -> type_env * string 
case d 
of VAL (x, e@) => (infer and bind type for VAL (x, e) for nano-ML 439b) 
| VALREC (x, e) => (infer and bind type for VALREC (x, e) for nano-ML 439c) 
| EXP e => typdef (VAL ("it", e), Gamma) 


| DEFINE (x, lambda) => typdef (VALREC (x, LAMBDA lambda), Gamma) 
(extra case for typdef used only in uML $435a) 
Forms EXP and DEFINE are syntactic sugar. 
The cases for VAL and VALREC resemble each other. A VAL computes a type and 
generalizes it. 


Ci,Tke:f 
OC is satisfied ar =T 
o = generalize(6r, ftv(T)) (vat) 
(vAL(x,e),T) > T{ar of 
439b. (infer and bind type for VAL (x, e) for nano-ML 439b)= (439a) 
let val (tau, c) = typeof (e, Gamma) 
val theta = solve c 
val sigma = generalize (tysubst theta tau, freetyvarsGamma Gamma) 


in (bindtyscheme (x, sigma, Gamma), typeSchemeString sigma) 
end 
This code takes a big shortcut: it assumes that Of = [’. That assumption is sound 
because a top-level [ never contains a free type variable (Exercise 10). This property 
guarantees that OC = I for any 0. 
A VALREC is a bit more complicated. The nondeterministic rule calls for an en- 
vironment that binds x to T, but 7 isn’t known until e is typechecked: 


T{zt+t}Fe:7 oo =generalize(r, ftv(T)) 


(vAL-REC(x,e), TP) 3 T{x o} (VALREC) 


The rule is made deterministic by initially using a fresh a to stand for 7, then once 
T is known, adding the constraint a ~ T: 


Ci,l{ara}Fe:r  aisfresh 
0(C Aa~r)issatisied OL =T 
o = generalize(6a, ftv([)) 


VALREC with traint: 
(VAL-REC(2, e), T) > {x nee o} ( with constraints) 


439c. (infer and bind type for VALREC (x, e) for nano-ML 439c)= 
let val alpha = freshtyvar () 
val Gamma' = bindtyscheme (x, FORALL ([], alpha), Gamma) 
val (tau, c) = typeof (e, Gamma') 
val theta solve (c /\ alpha ~ tau) 
val sigma = generalize (tysubst theta alpha, freetyvarsGamma Gamma) 
in (bindtyscheme (x, sigma, Gamma), typeSchemeString sigma) 
end 


(439a) 
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7.6.5 Primitives 


As in Typed psScheme, each primitive has a value and a type. Most of nano-ML’s 
primitives are just as in Typed wScheme; only a few are shown below. As in 
Chapters 5 and 6, the values are defined using higher-order functions unaryOp, 
binaryOp, and arithOp, which are defined in the Supplement. The values are un- 
changed, except that errors raise BugInTypeInference, not BugInTypeChecking. 

A primitive may have a polymorphic type scheme, but type schemes aren't 
coded directly. Instead, each primitive is coded with a type that may have free 
type variables, and when the primitive is installed in the initial type environment, 
its type is generalized. Types are shorter and easier to read than type schemes. 
440a. (primitives for nano-ML :: 440a)= ($425c) 

C"null?", unaryOp (fn NIL => BOOLV true | _ => BOOLV false), 
funtype ([listtype alpha], booltype)) :: 
C"cons", binaryOp (fn (a, b) => PAIR (a, b)), 
funtype ([alpha, listtype alpha], listtype alpha)) :: 
C"car", unaryOp 
(fn (PAIR (car, _)) => car 
| NIL => raise RuntimeError "car applied to empty list" 
[i => raise BugInTypeInference "car applied to non-list"), 
funtype ([listtype alpha], alpha)) :: 
Cede", unaryOp 
(fn (PAIR (_, cdr)) => cdr 
| NIL => raise RuntimeError "cdr applied to empty list" 
[2 => raise BugInTypeInference "cdr applied to non-list"), 
funtype ([listtype alpha], listtype alpha)) :: 

The other primitive worth showing here is error. Its type, Va,8.a— £, 
tells us something interesting about its behavior. The type suggests that error 
can produce an arbitrary 3 without ever consuming one. Such a miracle is im- 
possible; what the type tells us is that the error function never returns normally. 
In nano-ML, a function of this type either halts the interpreter or fails to terminate; 
in full ML, a function of this type could also raise an exception. 
440b. (primitives for nano-ML and ML :: 440b)= ($425¢c) 

C"error", unaryOp (fn v => raise RuntimeError (valueString v)), 
funtype ([alpha], beta)) :: 


The remaining primitives are relegated to the Supplement. 


7.6.6 Predefined functions 


Nano-ML’s predefined functions are nearly identical to wScheme’s predefined func- 
tions, except for association lists. In nano-ML, an association list is represented as 
a list of pairs, not a list of two-element lists. This representation is needed so that 
keys and values can have different types. And if a key in an association list is not 
bound, find can’t return the empty list, because the empty list might not have the 
right type—instead, find causes a checked run-time error. To avert such errors, 
nano-ML defines a bound? function. Functions bind, find, and bound? are defined 
in the Supplement; only their types are shown here: 
440c. (types of predefined nano-ML functions 440c)= 
(check-principal-type bind 
(forall ['a 'b] ('a 'b (list (pair 'a 'b)) -> (list (pair 'a 'b))))) 
(check-principal-type find 
(forall ['a 'b] ('a (list (pair 'a 'b)) -> 'b))) 
(check-principal-type bound? 
(forall ['a 'b] ('a (list (pair 'a 'b)) -> bool))) 


7.7. HINDLEY-MILNER AS IT REALLY IS 


The Hindley-Milner type system has been used in many languages, but the first is 
the one Milner himself worked on: Standard ML. In Standard ML, as in most other 
languages based on Hindley-Milner, a programmer can mix inferred types with 
explicit types. For example, instead of type-lambda, Standard ML allows explicit 
type variables after a val or fun keyword. And instead of @, Standard ML offers a 
type-ascription form (e€ : T). Where an @ form gives the type at which a polymorphic 
value is instantiated, an ascription gives the type of the resulting instance. As an 
example of explicit instantiation, the following Typed Scheme code instantiates 
polymorphic list functions nul1?, car, and cdr: 
441a. (sum function for Typed Scheme 441a)= 
(val-rec [sum : ((list int) -> int)] 
(lambda ([ns : (list int)]) 
(if ([@ null? int] ns) 
0 
(+ ([@ car int] ns) (sum ([@ cdr int] ns)))))) 


In Standard ML, type ascription can be used to give the types of the instances of the 
corresponding functions, null, hd, and t1, as well as the parameter ns: 
441b. (sum function for Standard ML 441b)= 
val rec sum = 
fn (ns : int list) => 
if (null : int list -> bool) ns then 0 
else (hd : int list -> int) ns + sum ((tl : int list -> int list) ns) 
The Hindley-Milner type system is just a starting point. A good next step is 

functional language Haskell, whose type system combines Hindley-Milner type in- 
ference with operator overloading. Most implementations of Haskell also support 
more general polymorphism; for example, the Glasgow Haskell Compiler provides 
an explicit forall that supports lambda-bound variables with polymorphic types. 


7.8 SUMMARY 


Type inference changed the landscape of functional languages. Milner (1978) pre- 
sented his type-inference algorithm just 4 years after Reynolds (1974) described the 
polymorphic calculus underlying Typed Scheme. Over 40 years later, although it 
has been extended and elaborated in many innovative ways, Milner’s type infer- 
ence remains a sweet spot in the design of typed languages. 

Milner’s original formulation manipulates only substitutions generated by uni- 
fication. From unifications to constraints is just a small step, but the constraint- 
based, “generate-and-solve” model of type inference has proven resilient and ex- 
tensible. For type inference today, it is the model of choice. 


7.8.1 Key words and phrases 


AT LEAST AS GENERAL The relation of a TYPE or a TYPE SCHEME to its INSTANCES. 
For example, a check-type test checks if an expression’s PRINCIPAL TYPE is 
at least as general as the type scheme written in the test. 


CONSTRAINT An EQUALITY CONSTRAINT. 


CONSTRAINT SOLVER An algorithm that finds a SUBSTITUTION that solves a CON- 
STRAINT. Constraint C' is solved by @ if all the SIMPLE EQUALITY CON- 
STRAINTS in OC relate identical TYPES. To work in type inference, a con- 
straint solver must find a MOST GENERAL substitution. 
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EQUALITY CONSTRAINT A constraint or requirement on TYPES that must be true if 
a program is to be well typed. Formed by writing conjunctions of SIMPLE 
EQUALITY CONSTRAINTS, each of which takes the form 7; ~ 79. 


GENERALIZATION The process of creating a TYPE SCHEME from a TYPE by quanti- 
fying over those free type variables that are not also free in the environment, 
if any. In ML, when an expression is bound to a LET-BOUND VARIABLE, its 
type is automatically generalized. 


INSTANCE A TYPE obtained from another type by SUBSTITUTING for type variables. 
Also, a TYPE SCHEME obtained from another type scheme by first substituting 
for bound type variables, then GENERALIZING over variables in the range of 
the substitution. 


INSTANTIATION The process of creating a TYPE from a TYPE SCHEME by substitut- 
ing for the quantified type variables, if any. In ML, when a variable is used, 
its type is automatically instantiated. 


A-BOUND VARIABLE A formal parameter to a function. Compare with LET-BOUND 
VARIABLE. 


LET-BOUND VARIABLE Avariable introduced by let, let*, letrec, val, or val-rec. 
Compare with \-BOUND VARIABLE. 


MONOTYPE A monomorphic type. May be a TYPE or may be a TYPE SCHEME that 
quantifies over an empty list of type variables. In ML, every \-bound variable 
has a monotype. Compare with POLYTYPE. 


MOST GENERAL Given a set of SUBSTITUTIONS, a substitution @ is a most general 
substitution if any other member of the set can be obtained by composing 0 
with another substitution. Or given a set of TYPES, a type 7 is a most general 
type if any other member of the set can be obtained from 7 by substitution. 


POLYTYPE A TYPE SCHEME that may be instantiated in more than one way. Thatis, 
one that quantifies over a nonempty list of type variables. In ML, only a let- 
bound variable may have a polytype. Compare with MONOTYPE. 


PRINCIPAL TYPE A type that can be ascribed to an expression such that any other 
type ascribable to the expression is an INSTANCE of the principal type. 
In other words, a MOST GENERAL type of an expression. Also used as short- 
hand for PRINCIPAL TYPE SCHEME, which is similar. In ML, principal type 
schemes are unique up to renaming of bound type variables. 


SUBSTITUTION A finite map from type variables to TYPES. Also defines maps from 
types to types, CONSTRAINTS to constraints, and others. 


TYPE In ML, a type formed using type constructors, type variables, and function 
arrows. Does not include any quantification. Compare with TYPE SCHEME. 


TYPE INFERENCE An algorithm that reconstructs and checks types in a program 
that does not necessarily include explicit type declarations for let-bound or 
A-bound variables. Also called TYPE RECONSTRUCTION. 


TYPE SCHEME A quantified type with exactly one universal quantifier, which is the 
outermost part of the type. The set of quantified variables may be empty, in 
which case the type scheme is equivalent to a TYPE. 


UNIFICATION An algorithm that finds a MOST GENERAL SUBSTITUTION that makes 
two types equal. Can be used to implement a CONSTRAINT SOLVER, or vice 
versa. 


7.8.2 Further reading 


The original work on the Hindley-Milner type system appears in two papers. Milner 
(1978) emphasizes the use of polymorphism in programming, and Hindley (1969) 
emphasizes the existence of principal types. Milner describes Algorithm W, which 
is the “method of explicit substitutions” in this chapter. Damas and Milner (1982) 
show that Algorithm W finds the most general type of every term. 

Odersky, Sulzmann, and Wehr (1999) present HM(X), a general system for im- 
plementing Hindley-Milner type inference with abstract constraints. This system 
is considerably more ambitious than nano-ML,; it allows a very broad class of con- 
straints, and it decouples constraint solving from type inference. Pottier and Rémy 
(2005) use the power of HM(X) to explore a number of extensions to ML. Their 
tutorial includes code written in the related language OCaml. 

Vytiniotis, Peyton Jones, and Schrijvers (2010) argue that as type systems grow 
more sophisticated, Milner’s LET rule makes it harder, not easier, to work with the 
associated constraints. They recommend that by default, the types of LET-bound 
names should not be generalized. 

In the presence of mutable reference cells, Milner’s LET rule is unsound. While 
the unsoundness can be patched by various annotations on type variables, a better 
approach is to generalize the type of a LET-bound variable only if the expression 
to which the variable is bound is a syntactic value, such as a variable, a literal, or 
a lambda expression (Wright 1995). 

Cardelli (1997) provides a general tutorial on type sytems. Cardelli (1987) has 
also written a tutorial specifically on type inference; it includes an implementation 
in Modula-2. The implementation represents type variables using mutable cells 
and does not use explicit substitutions. 

Peyton Jones et al. (2007) show how by adding type annotations, one can imple- 
ment type inference for types in which a V quantifier may appear to the left of an 
arrow—that is, types in which functions may require callers to pass polymorphic ar- 
guments. Such types are an example of higher-rank types. The authors present both 
nondeterministic and deterministic rules. The paper is accompanied by code, and 
it repays careful study. 

Material on Haskell can be found at www.haskell.org. A nice implementation 
of Haskell’s type system, in Haskell, is presented by Jones (1999). 


7.9 EXERCISES 


The exercises are summarized in Table 7.4 on the next page. There are many that 
I like, but type inference takes center stage. 


* In Exercises 18 and 19 (pages 448 and 449), you implement a constraint solver 
and finish the implementation of type inference. Before you tackle the con- 
straint solver, I recommend that you do Exercises 12 and 16, which will help 
you solve conjunction constraints in the right way. 


« Exercises 1 and 5 offer nice insights into properties of the type system. 


* In Exercises 21 to 23, you extend nano-ML. Of these exercises, Exercise 21 
(pair primitives) is probably the easiest, and it’s useful. But Exercise 22 offers 
the most satisfying benefit to the nano-ML programmer. 
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Table 7.4: Synopsis of all the exercises, with most relevant sections 


Exercises Section Notes 


1 Ch. 5 Using type inference to get a term of an unusual type. 

2 to 4 7.4.3 Substitutions: understand idempotence; confirm 
properties of the implementation; substitution preserves 
constraint satisfaction (§7.5.3). 

5 to 7 7.4 Principal types: equivalence, uniqueness up to 
equivalence. Most general instances of type schemes. 

8 toll 7.4,7.5 Writing constraint-based rules; consequences of the rules. 

12 to 15 7.5.3 Constraints: solvability of conjunctions, soundness of rules 
for the solver. 

16 to 20 7.5,7.6 Implementation of constraint solving and type inference. 

21 to 23 7.6 Extending nano-ML: pairs, a list constructor, mutable 
reference cells. 

24and25 7.6 Improving error messages; elaborating untyped nano-ML 


terms into Typed Scheme terms. 


7.9.1 Retrieval practice and other short questions 


A. 


Qn HY 


In lambda calculus, the type of the successor function on Church numerals is 
(Va.(a > a) > (a > a)) > (Va.(a > a) > (a > a)). This type is 
valid in Typed Scheme, with kind «, but it is not a valid Hindley-Milner type. 
Why not? 


In Typed Scheme, a programmer may instantiate any expression using the in- 
stantiation form, written with the @ operator. In nano-ML, instantiation is per- 
formed automatically. What syntactic forms are automatically instantiated? 


To ensure that types are well formed, Typed Scheme uses a system of kinds. 
Why doesn’t nano-ML need such a system? 


What kind of a thing is 0? What can a 6 be applied to? 
If # is applied to a type constructor ju, what are the possible results? 
What’s an example of a substitution that’s not idempotent? 


Function type int x int — int is printed as (int int -> int). How is it rep- 
resented in the nano-ML interpreter? 


The nondeterministic typing rule VAR includes judgment T < o. What does 
the judgment mean? Given a particular o, if we want a7 satisfying T < 0, how 
must such a T be formed? 


Suppose that I’’s only binding is {f +> Va.a —> 3}. What are Is free type 
variables? 


If o = generalize(r, A) and Ais empty, what do we know about the free type 
variables of a? 


In the nondeterministic type system, does term (lambda (x y) x) have type 
(int int -> int)? 


What is the principal type (or principal type scheme) of (lambda (x y) x)? 


In the initial basis, what principal type scheme should be assigned to the prim- 
itive function “nul1?”? 


sx GqH 


What’s the difference, if any, between substitution 0; o 02 and substitution 
Oo ie) 01? 


What’s the difference, if any, between constraint C; A C2 and constraint 
CoA Cy? 


What’s the difference, if any, between constraint 7, ~ T2 and constraint T) ~ 71? 


For type inference, why do I recommend against implementing the method of 
explicit substitutions? What’s an example of a typing rule that illustrates the 
difficulties of this method? 


Can the constraint a ~ bool be satisfied? If so, by what substitution? What 
about constraint a x int ~bool x a? What about constraint a x int ~bool x 3? 


If constraint T ~ T; — To is to be satisfied, what form must 7 have? 
If 6, solves C; and 02 solves C2, does 02 o 6; solve Cy A C2? 
What’s the algorithm for solving a constraint of the form C) A C2? 


In the interpreter, why does I have a different representation than it did in 
Chapter 6? 


Given a list of constraints C),...,C,,, what interpreter function do you call to 
combine them into a single constraint C) \---A\C;,? (The combined constraint 
may also be written \{C\,...,Cn}.) 


When a constraint can’t be solved, what interpreter function should you call? 


In chunk 438e, the combination of f and actuals into a single list is a little 
awkward. How does the code work? What’s the alternative? Why do you think 
I coded it this way? 


7.9.2 Manipulating type inference 


1. Functions with seemingly impossible types. 
(a) Without using any primitives, and without using letrec, write a func- 
tion in nano-ML that has type Va, 3 .a — £3. 


(b) Based on your experience, if you see a function whose result type is a 
P y' typ 
quantified type variable, what should you conclude about that function? 


7.9.3 Properties of substitutions 


2. Idempotence. A substitution 0 is idempotent if 00 6 = 0. 


(a) Give an example ofa substitution 0, = (a +4 T) thatis not idempotent. 
(b) Prove that 0, 00, £4 Ox. 
(c) Prove that if a ¢ ftv(7), then (a ++ T) is idempotent. 


(d) Instrument the |--> function in the interpreter so that if a € ftv(r), 
calling a |--> T raises the exception BugInTypeInference. 


3. Code that produces substitutions. Go back to function tysubst from Chapter 6 
on page 371, and look at the inner function subst, which is a function from 
types to types. Given that varenv is finite, show that subst satisfies each of 
the properties claimed for a substitution 9 on pages 409 and 410. 


4. Substitution preserves satisfaction. Look at the definition of satisfaction in Sec- 
tion 7.5.3, and prove that if constraint C is satisfied and 0 is a substitution, 
then OC is also satisfied. 
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7.9.4 Properties of type schemes and principal types 


5. 


Most general instances. Prove that for any type scheme o, there is a most general 
instance T < o. An instance 7 is a most general instance of o if and only if 
Vr. fo = 7' <7. 


Uniqueness of principal types. Principal types are unique up to renaming of 
variables. 


(a) Give an example of an environment and a term such that the term has 
more than one principal type. Show two different principal types. 


(b) Prove thatif['_ e: tp andI + e: rf andboth 7; and 77, are principal 
types for einT’, then rj, can be obtained from 7, by renaming variables. 


Use the definition of principal type on page 416. 


Equivalence of type schemes. The implementation of check-principal-type 
takes as inputs an expression e and a type scheme oa. It infers a principal 
type scheme og; for e, then checks to see that op is equivalent to 7. The two 
type schemes are equivalent ifo» < a anda < dp, which is to say that they 
have the same instances. But in the Definition of Standard ML, equivalence of 
type schemes is defined syntactically: 


Two type schemes o and o’ are considered equal if they can be 
obtained from each other by renaming and reordering of bound 
type variables, and deleting type variables from the prefix which 
do not occur in the body. [The prefix is the list of variables between 
the V and the dot. —NR] 


Prove that these definitions are equivalent. 


(a) Prove that renaming a bound type variable in o does not change its set 
of instances. 


(b) Prove that reordering bound type variables in o does not change its set 
of instances. It suffices to prove that adjacent type variables can be 
swapped without changing the set of instances. 


(c) Prove that if a type variable appears in the prefix of o but does not ap- 
pear in the body, then removing that variable from the prefix does not 
change the set of instances. 


(d) Conclude that if type schemes o and o’ are considered equal according 
to the Definition of Standard ML, then they have the same instances, and 
so they are also considered equal by check-principal-type. 


7.9.5 Typing rules and their properties 


8. 


Adding constraints to typing rules. Consulting the rules summary on pages 
450 and 451, rewrite these rules to use explicit constraints: 


(a) The rule for BEGIN: 


Tre:%, L<i<n 


. BEGIN 
[+ BEGIN(€1,..-,€n) : Tn ( ) 


(b) The rule for LAMBDA: 


T{ap ],...,int> mhre:r 


. LAMBDA 
TF LAMBDA((@1,...,2n),€) 271 X +++ X T OT : 


9. Recursive definitions. In nano-ML, the parser enforces the restriction that the 
right-hand side of a val-rec definition must be a lambda. But the typing 
rules permit a definition of the form (val-rec x x). Given this definition, 
what type scheme a do the rules say is inferred for x? Is that o inhabited by 
any values? In other words, is there a value that could be stored in p that is 
consistent with that o? 


10. Absence of free type variables in top-level type environments. Prove that in 


nano-ML, a top-level type environment never contains a free type variable. 87 2 
Your proof should be by induction on the sequence of steps used to create [’: Exercises 
447 


(a) Prove that an empty type environment contains no free type variables. 


(b) Using the code in chunk $425c, show that if I‘ contains no free type vari- 
ables, then addPrim((z, p, T), (I, ¢)) returns a pair in which the 
new I” also contains no free type variables. 


(c) Show that if T contains no free type variables, and if I’ is specified by 
(vAL(a, e),) + I”, then I’ contains no free type variables. 


(d) Show that if I contains no free type variables, and if I” is specified by 
(VAL-REC(x, e), I’) + I’, then I” contains no free type variables. 


11. Consistency of type inference with nondeterministic rules. Prove that whenever 
there is a derivation of a judgment @6[' | e : 7 using the rules for explicit 
substitutions in Section 7.5.1, then if I” = 61, there is also a derivation of 
I’ + e: T using the nondeterministic rules in Section 7.4.5. 


To prove this property for nano-ML would be tedious; nano-ML has too many 
syntactic forms. Instead, prove it for a subset, which I'll call “pico-ML,” and 
which has just these forms: lambda, function application, variable, and let. 
Both let and lambda bind exactly one name, and a function application has 
exactly one argument. 


What about the other direction? If there is a derivation using the nondeter- 
ministic rules, is there a corresponding derivation using explicit substitu- 
tions? Yes, but the corresponding derivation might not derive the same type. 
The most we can say about a type derivable using the nondeterministic rules 
is that it must be an instance of the type derived using type inference with 
explicit substitutions. The type derived using type inference is special, be- 
cause all other derivable types are instances of it; it is the term’s principal 
type. Proving that a principal type exists and that the type-inference algo- 
rithm finds one are problems that are beyond the scope of this book. 


7.9.6 Properties of constraints and constraint solving 
12. Solvability and conjunction. 
(a) Using the proof system in Section 7.5.3, prove that if the constraint 


C, A C2 is solvable, then constraints C and C2 are also solvable. 


(b) Finda particular pair of constraints C', and C2 such that C; is solvable, 
Cy is solvable, but C, A C2 is not solvable. Prove that Cy A C> is not 
solvable. 


13. Soundness of the SOLVEDCONJUNCTION rule. Using the definition of what it 
means for a constraint to be satisfied, prove that the SOLVEDCONJUNCTION 
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14. 


15. 


rule on page 429 is sound. That is, prove that whenever both premises hold, 
so does the conclusion. The rule is reproduced here: 
0,C, is satisfied 02(8,C2) is satisfied 
(82 0 81)(C1 A C2) is satisfied 


(SOLVEDCONJUNCTION) 


Soundness of the SOLVECONAPPCONAPP rule. Using the laws for applying sub- 
stitutions to constraints and to types, prove that the SOLVECONAPPCONAPP 
rule on page 430 is sound and complete. That is, prove that a substitution 0 
solves the constraint 
CONAPP(T, (71,---,7n)) ~ CONAPP(T’, (7],---;Tp)) 
if and only if it also solves the constraint 
TATA STA AT YT. 
Need for an occurs check. Prove that if T2 mentions a but is not equal to a, then 


there is no substitution # such that 9a = 67. (Hint: Count type construc- 
tors.) 


7.9.7 Implementation of constraint solving and type inference 


16. 


17. 


18. 


Practice with conjunction constraints. The most common mistake made in con- 
straint solving is to get conjunctions wrong (Section 7.5.3). Before you tackle 
a solver, this exercise asks you to develop some examples and to verify that 
the naive approach works sometimes, but not always. 


(a) Find two constraints C and C2 and substitutions 9; and @2 such that 
+ C has a free type variable, 
* Cy has a free type variable, 
* 6, solves C), 
* 02 solves C2, and 
* @ 0 8; solves Cy A Co. 
(b) Find two constraints C’; and C2 and substitutions 6, and 92 such that 
* C, has a free type variable, 
+ Cy has a free type variable, 
* 6; solves C1, 
* 02 solves C2, and 
* 02 0 @; does not solve C) A Co. 


Understanding a recursive solver. Page 431 discusses the solution of con- 
straint 7.1, which involves synthesizing and solving constraints 7.2 to 7.11. 
List the numbered constraints in the order that they would be solved by a recur- 
sive solver. 


Implementing a constraint solver. Using the ideas in Section 7.5.3, implement a 
function solve which takes as argument a constraint of type con and returns 
an idempotent substitution of type subst. (If a substitution is created using 
only the value idsubst and the functions |--> and compose, and if |--> is 
used as described in Exercise 2, then the substitution is guaranteed to be 
idempotent.) The resulting substitution should solve the constraint, obeying 
the law 
solves (solve C, C). 


If the constraint has no solution, call function unsatisfiableEquality from 
chunk 437a, which raises the TypeError exception. 


19. 


20. 


Implementing type inference. Complete the definitions of functions ty and 
literal so they never raise LeftAsExercise. If your code discovers a type 
error, it should raise the exception TypeError. 


The function literal must give a suitable type to integer literals, Boolean 
literals, symbol literals (which have type sym), and quoted lists in which all 
elements have the same type (including the empty list). For example, the 
value '(123) must have type int list. Values created using CLOSURE or 
PRIMITIVE cannot possibly appear in a LITERAL node, so if your literal 
function sees such a value, it can raise BugInTypeInference. 


You will probably find it helpful to refer to the typing rules for nano-ML, 
which are summarized in Figures 7.5 to 7.8 on pages 450 and 451. And don't 
overlook the typesof function. 


Constraint solving from unification. Milner’s original formulation of type in- 
ference relies on unification of explicit substitutions. To show that unifica- 
tion is as powerful as constraint solving, suppose that you have a function 
unify such that given any two types 7, and 72, unify(7,, T2) returns a sub- 
stitution 6 such that 67, = 672, or if no such @ exists, raises an exception. 
Use unify to implement a constraint solver. 


Hint: To help convert a constraint-solving problem into a unification prob- 
lem, try using the SOLVECONAPPCONAPP rule on page 430 in reverse. 


7.9.8 Extending nano-ML 


21. 


22. 


Pair primitives. Extend nano-ML with primitives pair, fst, and snd. Give the 
primitives appropriate types. Function pair should be used to create pairs 
of any type, and functions fst and snd should retrieve the elements of any 
pair. 


A list constructor. In nano-ML, the most convenient way to build a large list is 
by using a large expression that contains a great many applications of cons. 
But as described in the sidebar on page 430, type inference using my data 
structures requires time and space that is quadratic in the number of appli- 
cations of cons. The problem can be addressed through more efficient repre- 
sentations, but there is a surprisingly simple fix through language design: ex- 
tend nano-ML with a LIST form of expression, which should work the same 
way as Standard ML’s square-bracket-and-comma syntax. The form should 
obey this rule of operational semantics: 


(e1,p) bor + (ens p) bon 
UV = PAIR(V1, PAIR(V2,--., PAIR(Un, NIL))) | de 
(LIST(€1,..-,€n),p) Lv 
And here is a nondeterministic typing rule: 
Tre,:T oo SK (isi) 
[TE List(e1,...,€n) : 7 list 


Implement a list constructor for nano-ML, in the following four steps: 


(a) Extend the abstract syntax for exp with a case LIST of exp list. 


(b) Extend the parser to accept (list e; --- €,) to create a LIST node. 
As a model, use the parser for begin. 


(c) Extend the evaluator to handle the LIST case. 
(d) Extend type inference to handle the LIST case. 
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VAR 
T(a)=o0 TKX<o 


Thre: 
Thka:rt 
IF 
T+ e, : bool Tbh eg:T Th e3:T 
ML and type TF 1F(e1, €2,€3) : T 
inference ore: 
456 Pepe: Poon The: X+++X TOT 
[TF AppPLy(e,e1,...,€n) 27 
LAMBDA 
T{ap ],.--,int mphee:r 
TF LAMBDA((21,...,2n),€) 271 X +++ X Tn OT 
LET 


Tre:%, l<i<n 
o; = generalize(7;,ftv(T)), lL<i<n 


T{a1 04,...,an ons e:T 
TE LET((a1,€1,---,;%n,€n),€) 2 T 

LETREC 
IY =Tf{a, + ,...,2n 9 Tr} 


VMre:%, l<i<n 
o; = generalize(7,,ftv([)), l<i<n 


T{a1 > 04,...,2n onpbre:T 
[TF LETREC((@1,€1,---,;@n;€n),€) 2 T 
LETSTAR 
TF Let((1, €1), LETSTAR((%2,€2,.--,2n,€n),€)):T n>O 
[TF LETSTAR((21,€1,---,2n,€n),€) 2 T 
EMPTYLETSTAR BEGIN 
Tre:7T Tre:%, l<i<n EMPEUPEE IN 
I+ LETSTAR((),e) : 7 TF BEGIN(€1,...,€n) : Tr I+ BEGIN() : unit 


Figure 7.5: Nondeterministic typing rules for expressions 


VAL 
anor Thte:t  o =generalize(r, ftv(I)) 
(vAL(x,e),C) > T{a o} 
VALREC EXP 
T{twr}he:r oo =generalize(r, ftv(T)) (vAL(it, e),T) >I’ 
(VAL-REC(z, e), [) > P{a+ o} (exP(e),T) > I” 
DEFINE 
(VAL-REC(f, LAMBDA((71,...,2n),e)),) +I” 


(DEFINE(f, ((71,.-.,%n),e)), 0) +I” 


Figure 7.6: Nondeterministic typing rules for definitions 


VAR 
T(x) = Vay,...,Qn-T 


ai,..., a, are fresh and distinct 


C,Tre:r 
, TD a@: ((ay + a})0-++0 (an 4 al,)) 7 
IF 
§7.9 
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APPLY 
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CAF T X+++ XT a,b APPLY(e,€1,...,€n) 2 @ 
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CHIC Ee hes ten STs een, 
OC is satisfied (is idempotent 
C' = \{a~ da|ae€ domén ftv(T)} 
oj = generalize(07;,ftv([) Uftv(C’)), L<i<n 
Cy, T{a1 > 01,.-.,;an ons e:r 
CO’ AC, TE Let((21, €1,.<:52n;€n),€) 2 T 


LETREC 
€1,---,€n are all LAMBDA expressions 
IY =T{a1 + a1,...,2n > Oy}, where all a;’s are distinct and fresh 
Cp Pein CRE sk 


C=C. AM ~ ay A+++ AT ~ An 
OC is satisfied is idempotent 
C' = \{a~ da|ae€ domén ftv(T)} 
oj = generalize(07;,,ftv([) Uftv(C’)), l<i<n 
Cy, T {a1 01,...,an ons e:r 
C’ A Cy, TF LETREC((21, €1,---52n,€n),€) 2 T 


Figure 7.7: Constraint-based typing rules for expressions 


VAL 
CiTFe:r 
OC is satisfied éaV=T 
o = generalize(6r, ftv(T)) 


(vaL(x,e),T) > T{a+ o} 


(d,T) 31° 


VALREC with constraints 
CI{ara}te:r — aisfresh 


6(CAa~r)issatisfied OC =T 
o = generalize(0a, ftv(T)) 
(VAL-REC(2,e),T) > {a4 o} 


Figure 7.8: Constraint-based typing rules for definitions 


23. Mutable reference cells and the value restriction. 


(a) Add new primitives ref, !, and := withthe same meanings asin full ML. 
You will have to use ML “ref cells” to add a new form of value, and 
you will have to extend the primitiveEquality function to compare 
ref cells for equality. But you should not have to touch environments or 
the evaluator. 


(b) Write a program in extended nano-ML that subverts the type system, 


vee and type i.e., that makes the evaluator raise the exception BugInTypeInference. 
hferenie For example, try writing a program that applies + to a non-integer ar- 
452 gument. (Hint: (ref (lambda (x) x)).) 


(c) Restore type safety by implementing the “value restriction” on poly- 
morphism: the type of val-bound name is generalized only if the name 
is bound to syntactic value (a variable, a literal, or a \-abstraction). 


7.9.9 Improving the interpreter 


24. Improved error messages. Improve the interpreter’s error messages: 


(a) If a type error arises from a function application, show the function 
and show the arguments. Show what types of arguments the function 
expects and what the types the arguments actually have. 


(b) If a type error arises from an IF expression, show either that the type 
of the condition is inconsistent with bool or that the two branches do 
not have consistent types. 


(c) Highlight the differences between inconsistent types. For example, if 
your message says 


function cons expected int * int list, got int * int, 


this is better than saying “cannot unify int and int list,” but it is not 
as good as showing which argument caused the problem, e.g., 


function cons expected int * >>int list<<, got int * >>int<<. 


To complete this part, it would be helpful to define a more sophis- 
ticated version of unsatisfiableEquality, which returns strings in 
which types that don’t match are highlighted. 


To associate a type error with a function application, look at the APPLY rule 
on page 421 and see whether the constraint in the premise is solvable, and 
if so, whether the constraint in the conclusion is solvable. 


25. Elaboration into explicitly typed terms. Change the implementation of type 
inference so that instead of inferring and checking types in one step, the 
interpreter takes an untyped term and infers an explicitly typed term in 
Typed Scheme. Adding information to the original code is an example of 
elaboration. I recommend copying the syntax of Typed wScheme into a sub- 
module of your interpreter, as in 


structure Typed = struct 
datatype exp =.. 
end 


You can then translate LAMBDA to Typed.LAMBDA, and so on. 


PART II. PROGRAMMING 
AT SCALE 


Programming at scale is supported by many techniques, tools, and language fea- 
tures, but the key enabling idea is to hide information. The role of a programming 
language is to hide information about the representation of data, which is called 
data abstraction. There are two techniques: abstract data types, which uses a type 
system to limit access to representation, and objects, which uses environments to 
limit access to representation. These ideas are illustrated by the languages Mole- 
cule (Chapter 9) and psSmalltalk (Chapter 10). 

To write programs at scale, particularly if you want to describe representations 
using a type system, you need more data types than can be found in languages 
like Typed Impcore, Typed Scheme, and nano-ML. To provide suitable types, this 
part of the book begins with jsML, which extends nano-ML with user-defined types. 
LLML’s algebraic data types give programmers the ability to group parts together, to 
express choices among forms of a single representation, and to define recursive 
representations. They also support pattern matching. 

Molecule starts with jsML’s data representation and with Typed sScheme’s type 
system, adding a modules system that can describe interfaces and implementa- 
tions. Like Typed wScheme, Molecule requires no type inference, only type check- 
ing. 

Smalltalk introduces a different programming paradigm: objects. Code 
doesn’t call functions; instead, it sends messages to objects, and these messages are 
dispatched dynamically to methods. In ppzSmalltalk, methods are defined by classes, 
and classes can inherit methods from other classes. Dynamic dispatch and inher- 
itance are simple mechanisms, but they have far-reaching consequences. Using 
them well enables new forms of reuse but requires new ways of thinking. 

Molecule and psSmalltalk provide data abstraction in different ways. Both hide 
representations except from code that is inside the abstraction, but what’s consid- 
ered “inside” is different. Within a Molecule module, an operation can see the rep- 
resentation of any value of any abstract type defined inside the module. Within a 
Smalltalk class, an operation can see the representation of just one object: the 
object on which the operation is defined. The representations of other objects are 
hidden. These different forms of information hiding lead to different kinds of flex- 
ibility. Using Molecule’s abstract data types, it is easy to define operations that in- 
spect multiple representations, like an efficient merge of leftist heaps. But it is 
impossible to define operations that work with new abstractions defined outside 
the operation’s cluster: each operation works only with arguments that have the 
static types given in its signature. Using Smalltalk’s objects, it is possible to define 
operations that inspect multiple representations, but to do so requires exposing 
the representation, violating abstraction. But if abstraction is not violated, then it 
is easy to use existing operations with new representations: each operation works 
with any object that responds correctly to the messages in the specification’s pro- 
tocol. These differences in visibility and interoperability are essential differences 
that apply when comparing any language that uses abstract data types with any 
language that uses objects. 

Other differences between Molecule and Smalltalk apply to a more limited set 
of languages. For example, Molecule provides code reuse through parametric poly- 
morphism, and pSmalltalk provides code reuse through inheritance. But a lan- 
guage can have abstract data types without having parametric polymorphism, and 
a language can also have objects without having classes and inheritance. There are 
also incidental differences; for example, a Molecule module controls which oper- 
ations are exported to client code, but a Smalltalk class exposes all operations to 
every client. In the context of its language’s semantics, each decision makes good 
design sense. 
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Representation is the essence of programming. ... 
Much more often, strategic breakthrough will come from 
redoing the representation of the data or the tables. 
This is where the heart of a program lies. Show me 
your flowcharts and conceal your tables, and I shall 
continue to be mystified. Show me your tables, and I 
won't usually need your flowcharts; they’ll be obvious. 


Fred Brooks, The Mythical Man-Month, Chapter 9 


Chapters 1 to 7 don’t give us many ways to organize data. S-expressions are great, 
but you might have noticed that they serve as a kind of high-level assembly language 
on top of which you have to craft your own data structures. For programming at 
scale, that’s not good enough—programmers need to define proper data structures 
whose shapes and contents are known. Proper data-definition mechanisms must 
be able to express these possibilities: 


* Data can take multiple forms, like a C union. 
* Data can have multiple parts, like a C struct. 


* One or more parts may be like the whole, that is, data can be recursive. 


All these possibilities can be expressed using algebraic data types. Algebraic data 
types, supplemented by the base types, function types, and array types shown in 
previous chapters, suffice to describe and typecheck representations of data at any 
scale. They are ubiquitous in the ML family and in languages derived from it, in- 
cluding Standard ML, OCaml, Haskell, Agda, Coq/Gallina, and Idris. 

Algebraic data types can be added to any language; this chapter adds them to 
nano-ML, making the new language sML. To add algebraic data types requires a 
new species of value, a new expression form for looking at the values, and a new 
definition form for introducing the types and values. 

The new species of value is a constructed value. A constructed value is made 
by applying some value constructor to zero or more other values. In the syntax, 
however, zero-argument value constructors aren't applied; a zero-argument value 
constructor is a value all by itself. For example, '() is a value constructor for lists, 
and it expects no arguments, so it is a constructed value. And cons is also a value 
constructor for lists, but it expects arguments, so to make a constructed value, cons 
must be applied to two other values: an element and a list. 

A constructed value is interrogated, observed, or eliminated scrutinized by a 
case expression. A case expression provides concise, readable syntax for asking a 
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key question about any datum: how was it formed, and from what parts? A case ex- 
pression gets the answer by using patterns: a pattern can match a particular value 
constructor, and when it does, it can name each of the values to which the con- 
structor was applied. For example, the pattern (cons y ys) matches any cons cell, 
and when it matches, it binds the name y to the car and ys to the cdr. 

Case expressions and pattern matching eliminate the clutter associated with 
functions like nu11?, car, cdr, fst, and snd. Instead of using such functions, you 
lay out the possible forms of the data, and for each form, you name the parts di- 
rectly. The resulting code is short and clear, and it operates at a higher level of 
abstraction than Scheme code or C code. With the right syntactic sugar, your code 
can look a lot like algebraic laws (Section 8.4). 

Acase expression inspects a scrutinee, and it includes a sequence of choices, each 
of which associates a pattern with a right-hand side. And if the choices don’t cover 
all possible cases, a compiler can tell you what case you left out (Exercise 38). As an 
example, a case expression can be used to see if a list is empty; the scrutinee is the 
formal parameter xs, and there are two choices: one for each form of list. 


458. (predefined {ML functions 458) = 464d > 
(define null? (xs) null? : (forall ['a] ((list 'a) -> bool)) 
(case xs 
[(cons y ys) #t] 
['C #f1)) 


Each choice has a pattern on the left and a result on the right. 

Patterns are formed using value constructors, and each value constructor be- 
longs to a unique type. The type and its constructors are added to a basis (a type 
environment and a value environment) by a new form of definition: the data defi- 
nition. In ML, this definition form comes in two flavors: “implicit” and “explicit.” 
The implicit-data form mimics Standard ML’s datatype form; it is simple and 
almost impossible to get wrong. But implicit-data is actually syntactic sugar for 
LML’s explicit data form, which states, in full, the kind of the new type and the 
types of its value constructors. 

A data definition can name the new type whatever it wants. For example, a new 
algebraic data type can be called int, in which case it hides the built-in int. In the 
interpreter, such type names are translated into internal types (Section 8.5). 

Algebraic data types support new programming practices and also require new 
theoretical techniques, both of which are addressed in this chapter. 


* Programming practices, which will help you learn enough Standard ML to 
be able to work on the interpreters that appear from Chapter 5 onward, are 
illustrated by programming examples (Sections 8.1 and 8.2), an informal de- 
scription of evaluation (Section 8.2), and some easy exercises (Section 8.11). 
As in Chapter 2, programming can include equational reasoning about code 
that uses algebraic data types (Section 8.3), and itcan be made more pleasant 
by syntactic sugar, which is used routinely in languages like ML and Haskell 
(Section 8.4). 


* To know when two types are different, even when they have the same struc- 
ture, requires a theory of type generativity (Section 8.5). Algebraic data 
types also require type theory and operational semantics that describe user- 
written type definitions (Section 8.7) and case expressions with pattern 
matching (Section 8.8). The theory and semantics are implemented in my 
interpreter. 


Skills in both theory and implementation can be developed through the exercises 
at the end of the chapter. 


8.1 CASE EXPRESSIONS AND PATTERN MATCHING 


To understand what you can do with algebraic data types, study the case expression, 
which is described by this fragment of jsML’s grammar: 


exp = (case exp { choice} ) 
choice ::= [pattern exp] 
pattern ::= variable-name 


| value-constructor-name 
| (value-constructor-name { pattern} ) 


A case expression looks at a constructed value—called the scrutinee—and asks two 
questions: What value constructor was used to make it? And what values, if any, 
was that constructor applied to? In other words, the case expression asks how the 
scrutinee was formed and from what parts. Let’s work some examples. 


Value constructors that take no arguments 


Asan example, I define type traffic-light; a value of type traffic-light is made 
by one of the value constructors RED, GREEN, or YELLOW. The type and its value con- 
structors are introduced by this implicit-data definition: 


459a. (transcript 459a) = 459b > 
-> (implicit-data traffic-light 
RED 
GREEN 
YELLOW) 
traffic-light :: * 
RED : traffic-light 
GREEN : traffic-light 
YELLOW : traffic-light 


The definition extends the basis with the information shown: the name and kind of 
the new type, traffic-light, plus the name and type of each new value construc- 
tor. These value constructors take no arguments, so the only values of the new type 
are RED, GREEN, and YELLOW 

Using a case expression, I can define a function to change a light. 


459b. (transcript 459a) += <1459a 460ab 
change-light : (traffic-light -> traffic-light) 
-> (define change-light (light) 
(case light 

[GREEN YELLOW] 

[YELLOW RED] 

[RED GREEN])) 
-> (change-light GREEN) 
YELLOW : traffic-light 


When function change-light is applied, the case expression is evaluated as fol- 
lows: First, expression light is evaluated to produce GREEN. Next, the value GREEN 
is matched to each choice in turn; each choice has a pattern on the left and an expres- 
sion on the right. When a pattern matches the value GREEN, that choice is selected, 
and the expression on its right-hand side is evaluated. In this example, the very first 
choice is [GREEN YELLOW], GREEN matches GREEN, and so (change-light GREEN) re- 
turns the right-hand side, YELLOW. 
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As another example, here’s a function that says what the light means: 


460a. (transcript 459a) += <1459b 460b> 
-> (define light-meaning (light) light-meaning : (traffic-light -> sym) 
(case light 
[RED "stop] 
[GREEN 'go] 
[YELLOW 'go-faster])) 
-> (light-meaning GREEN) 
go : sym 
Again, light evaluates to GREEN. The first choice has pattern RED, which doesn’t 
match GREEN. The second choice has pattern GREEN, which does match GREEN, and 
the result is the right-hand side: green means 'go. 
Multiple constructed values can be inspected with multiple case expressions. 
As an example, two traffic lights can be compared to see if one is safer to drive 
through. To compute that GREEN is safer than YELLOW, I use nested case expressions: 
460b. (transcript 459a) += <1460a 460c> 
safer? : (traffic-light traffic-light -> bool) 
-> (define safer? (light1 lighte) 
(case light1 
[GREEN (case light2 
[GREEN #f] 
[YELLOW #t] 
[RED #t])] 
[YELLOW (case light2 
[GREEN #f] 
[YELLOW #f] 
[RED #t])] 
[RED #f])) 
safer? : (traffic-light traffic-light -> bool) 
-> (safer? GREEN YELLOW) 
#t : bool 


In this example, light1 evaluates to GREEN, and the first pattern matches. On the 
right-hand side, the inner case first evaluates light2 to get YELLOW, then finds that 
the pattern in the second choice matches, and finally returns the right-hand side #t. 


Nested patterns 


Nested case expressions can be ugly and hard to read; they don’t make it obvious 
what is being compared. A more idiomatic comparison forms a pair and scruti- 
nizes it using nested patterns. In a nested pattern, a value constructor is applied to 
one or more patterns that are also formed using value constructors. In this exam- 
ple, I nest value constructors for traffic-light inside the predefined PAIR value 
constructor, as in the nested pattern (PAIR GREEN YELLOW). 


460c. (transcript 459a) += <1460b 461aD 
-> (define safer? (light1 lighte) 
(case (PAIR light1 lighte2) 
[CPAIR GREEN GREEN) #f] 
[CPAIR GREEN YELLOW) #t] 
[CPAIR GREEN RED) #t] 
[CPAIR YELLOW GREEN) #f] 
[CPAIR YELLOW YELLOW) #f] 
[CPAIR YELLOW RED) #t] 
[CPAIR RED GREEN) #f] 
[CPAIR RED YELLOW) #f] 
[CPAIR RED RED) #f])) 
safer? : (traffic-light traffic-light -> bool) 


This time the expression (PAIR light1 light2) is evaluated, and it produces the 
value (PAIR GREEN YELLOW). When this value is scrutinized in the case expression, 
the second choice matches it, and the result is the right-hand side #t. 
461a. (transcript 459a) += <1460c 461b> 
-> (safer? GREEN YELLOW) 


#t : bool 


Patterns with wildcards 


Nested patterns make it easy to write out an entire truth table, but an entire truth 
table can get big. To write fewer patterns, I use the “wildcard” pattern, written with 
a single underscore, which means “match anything; I don’t care.” To test safety at 
traffic lights, “I don’t care” can be used with every color: 


* Green is no safer than itself but is safer than anything else—I don’t care what. 
* Yellow is safer than red but not safer than anything else—I don’t care what. 


* Red is not safer than anything—I don’t care what. 


These shortcuts are coded as follows: 


461b. (transcript 459a) += <461a 461c> 
-> (define safer? (light1 lighte) 
(case (PAIR light1 light2) 


[(PAIR GREEN GREEN) #f] 


[(PAIR GREEN _) #t] 
[(PAIR YELLOW RED) #t] 
[(PAIR YELLOW _) #f] 
[(PAIR RED =) #f])) 

-> (safer? GREEN YELLOW) 

#t : bool 

-> (safer? RED GREEN) 

#f : bool 

-> (safer? YELLOW RED) 

#t : bool 


In many programming problems, wildcard patterns can be used to avoid enumer- 
ating all cases explicitly. 


Value constructors that take arguments 


From here, let’s assume the lights are green, and let’s ask how fast we can drive. 
If, like me, you drive between the U.S. and Canada, it’s not always easy to know— 
my countrymen can’t agree with the Canadians on what constitutes a speed. 


* In the U.S., a speed is (MPH n), where nis a number. 


* In Canada, a speed is (KPH n), where n is a number. 


This sad situation can be expressed by defining an algebraic data type. Unlike RED, 
GREEN, and YELLOW, MPH and KPH are value constructors that take arguments: 


461c. (transcript 459a) += <1461b 462aD 
-> (implicit-data speed 
[MPH of int] 
[KPH of int]) 
speed :: * 
MPH : (int -> speed) 
KPH : (int -> speed) 


To make a speed, apply MPH to an integer, or apply KPH to an integer. 
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Now I can answer questions about driving. Towns in Quebec usually have local 
speed limits of 50 kph. Towns in New England usually have local speed limits of 25 
or 30 mph. Given that a kilometer is 5/8 of a mile, which is faster? 


462a. (transcript 459a) += <1461c 462b> 
-> (define speed< (speed1 speed2) speed< : (speed speed -> bool) 
(case (PAIR speedi speed2) faster : (speed speed -> speed) 
User-defined, [(PAIR (MPH n1) (MPH n2)) (< ni ne)J 
algebraic types (and [(PAIR (KPH n1) (KPH n2)) (< ni n2)] 


[(PAIR (MPH n1) (KPH n2)) (< (* 5 n1) (* 8 n2))] 
[(PAIR (KPH n1) (MPH n2)) (< (* 8 nt) (* 5 n2))])) 
462 -> (define faster (speed1 speede) 

(if (speed< speedi speed2) speed2 speed1)) 
-> (faster (KPH 50) (MPH 30)) 
(KPH 50) : speed 


pattern matching) 


Data types with polymorphic constructors 


What really matters is whether I’m obeying the speed limit. In Quebec and New 
England, a speed limit is just a speed. But in parts of western North America and 
Europe, there is no speed limit. So a speed limit could be represented as one of the 
following: 


* (SOME s), where the posted speed limit is a speed s 


* NONE, where there is no posted speed limit 


462b. (transcript 459a) += <1462a 462c> 
-> (define legal-speed? legal-speed? : (speed (option speed) -> bool) 
(my-speed limit) 
(case limit 
[CSOME max) (not (speed< max my-speed))] 
[NONE #t])) 


Can I go 65 mph in a 110 kph zone? On the autobahn, if there is no speed limit? 


462c. (transcript 459a) += <1462b 462d> 
-> (legal-speed? (MPH 65) (SOME (KPH 110))) 
#t : bool 
-> (legal-speed? (MPH 65) NONE) 
#t : bool 


Value constructors SOME and NONE have many more uses. For example, they can 
describe the result of looking up a key k in an association list: 

* (SOME v), if key & is associated with value v 

* NONE, if key k is not present 


They can also describe the result of reading a line from a file: 


* (SOME s), where s is a string representing the next line from the file 
* NONE, if the end of the file has been reached 
If SOME can be used with a speed, or a string, or a value of unknown type, what 


type must it have? A polymorphic type. Value constructors SOME and NONE belong 
to WML’s built-in option type, which is copied from full Standard ML. 


462d. (transcript 459a) += <1462c 463c> 
-> SOME 
<function> : (forall ['a] ('a -> (option 'a))) 
-> NONE 


NONE : (forall ['a] (option 'a)) 


The option type is not primitive; it is predefined using ordinary user code. 
Its definition uses the explicit data form, which gives the kind of the option type 
constructor and the full types of the SOME and NONE value constructors: 
463a. (predefined ML types 463a)= 473aD 
(data (* => *) option 
[SOME : (forall ['a] ('a -> (option 'a)))] 


[NONE : (forall ['a] (option 'a))]) $8.1 . 
; : : . Case expressions 
If you prefer less notation, any algebraic data type in WML can also be defined using and pattern 
implicit-data: matching 
463b. (transcript of implicit definitions 463b)= 
-> (implicit-data ['a] option 463 
NONE 
[SOME of 'a]) 
option@f2ez :: (* => *) 
NONE : (forall ['a] (option@g2? 'a)) 
SOME : (forall ['a] ('a -> (option@g2? 'a))) 
But what is option@{23?! It is the print name of the option type just defined. The 
suffix “@{2?” lets you know that this type is a redefinition of the option type built 
into UML. Types option and option@{2? are incompatible; a function that works 
with one won't work with the other. This incompatibility is a consequence of the 
generativity of datatype definitions (Section 8.5). 
No matter how NONE and SOME are defined, they are polymorphic. And if they 
are used in a function, that function may also be polymorphic. As an example, 
function get-opt takes a value of type (option 'a) and a default value of type ‘a, 
and it returns either the option value or the default: 
463c. (transcript 459a) += <1462d 463d> 
get-opt : (forall ['a] ((option 'a) 'a -> 'a)) 
-> (define get-opt (maybe default) 
(case maybe 
[(SOME a) a] 
[NONE default])) 
get-opt : (forall ['a] ((option 'a) 'a -> 'a)) 
Recursive data types 
In a datatype definition, a value constructor can take an argument of the type being 
defined—which makes the data type recursive. The best simple example is a list; 
another good, simple example is a binary tree. At each internal node, a simple 
0 vi 7 append B 
binary tree might carry one value of type ‘a, plus left and right subtrees: raat 46ic 
463d. (transcript 459a) += <1463c 463e> MPH 461c 
-> (data (* => *) bt NONE B 
[BTNODE : (forall ['a] (‘a (bt 'a) (bt 'a) -> (bt 'a)))] Pi B 
SOME B 


[BTEMPTY : (forall ['a] (bt 'a))]) 
bt :: (* => *) 
BTNODE : (forall ['a] ('a (bt 'a) (bt 'a) -> (bt 'a))) 
BTEMPTY : (forall ['a] (bt 'a)) 


type speed 461c 


Such a tree’s elements can be listed in preorder (node before children): 
463e. (transcript 459a) += <1463d 464aD 
preorder-elems : (forall ['a] ((bt 'a) -> (list 'a))) 
-> (define preorder-elems (t) 

(case t 

[BTEMPTY '()] 

[(BTNODE a left right) 

(cons a (append (preorder-elems left) (preorder-elems right)))])) 


And a test case: 
464a. (transcript 459a) += <1463e 464b> 
-> (define single-node (a) single-node : (forall ['a] ('a -> (bt 'a))) 


(BTNODE a BTEMPTY BTEMPTY)) 
=> (val int-bt 


(BTNODE 1 
User-defined, CBTNODE 2 
algebraic types (and pee seas 
: single-node 
pattern matching) (BTNODE 4 
464 (BTNODE 5 


(single-node 6) 
(single-node 7)) 
(single-node 8)))) 

-> (preorder-elems int-bt) 
(1234567 8) : (list int) 
For a binary search tree, which our example is not, the classic traversal is an inorder 

traversal: left subtree before node before right subtree. 
464b. (transcript 459a) += <1464a 464c> 
inorder-elems : (forall ['a] ((bt 'a) -> (list 'a))) 


-> (define inorder-elems (t) 
(case t 
[BTEMPTY '()] 
[(BTNODE a left right) 
(append (inorder-elems left) (cons a (inorder-elems right)))])) 
-> (inorder-elems int-bt) 
(231657 4 8) : (list int) 
Like lists, binary trees support operations that map, filter, and fold. 
464c. (transcript 459a) += <1464b 465> 
bt-map : (forall ['a 'b] (('a -> 'b) (bt 'a) -> (bt 'b))) 
-> (define bt-map (f t) 
(case t 
[BTEMPTY BTEMPTY] 
[(BTNODE a left right) 
(BTNODE (f a) (bt-map f left) (bt-map f right))])) 
-> (preorder-elems (bt-map (lambda (n) (* n n)) int-bt)) 
(1 4 9 16 25 36 49 64) : (list int) 


A fold function for a binary search tree is part of Exercise 14. 
Data types with just one value constructor each 


Most often, an algebraic data type defines more than one way to form a constructed 
value—that is, more than one value constructor. But an algebraic datatype can use- 
fully have just a single constructor, as shown by the pair type: 
464d. (predefined 1ML functions 458) += <1458 464e> 
(data (* * => *) pair 
[PAIR : (forall ['a 'b] ('a 'b -> (pair 'a 'b)))]) 
Using this definition, functions pair, fst, and snd don’t have to be implemented as 
primitives the way they do in nano-ML,; they are defined using ordinary user code: 
464e. (predefined ML functions 458) += <1464d 474c> 
(val pair PAIR) 
(define fst (p) 
(case p [(PAIR x _) x])) 
(define snd (p) 
(case p [(PAIR _ y) y])) 


(Because pattern matching is more idiomatic, functions fst and snd are rarely 
used, but they are included for compatibility with nano-ML.) 
Single-constructor types like pair are typically used in two different ways: 


* When the single constructor takes multiple arguments, like PAIR, the alge- 
braic data type acts as arecord type. This usage can be supported by syntactic 
sugar; jJML provides a record definition form, which desugars into datatype §8.1 


definition and a sequence of function definitions. Case expressions 
and pattern 
* When the single constructor takes a single argument, the algebraic data type matching 


acts as a renaming of some other type. The types that are most commonly 
renamed are types that are used with many meanings, like integers and 
Booleans; for example, in order to distinguish a height from a weight, we 
might rename int: 


465 


465. (transcript 459a) += <1464c 470b> 
-> (data * height [HEIGHT : (int -> height)]) 
-> (data * weight [WEIGHT : (int -> weight) ]) 
-> (val h (HEIGHT 196) ) 
(HEIGHT 196) : height 
-> (val w (WEIGHT 87)) 
(WEIGHT 87) : weight 


In full ML, this kind of renaming has zero run-time cost; at run time, 
(HEIGHT 196) is represented in exactly the same way as just 196. 


Sum of products: A universal representation 


Algebraic data types can express all the possibilities we demand from a “proper” 
type-definition mechanism. These possibilities can be expressed in the language 
of type theory: 


+ A type whose values can take on multiple forms is called a sum type. 
- A type that gathers multiple parts is called a product type.' 
+ A type with a part that is like the whole is called a recursive type. 


At first glance, an algebraic data type appears to be just a sum type: each form 
corresponds to a value constructor. But because each value constructor may carry 
any number of parts, an algebraic data type is a sum of products. And it expresses 
the others as special cases: Omit carried values, as in traffic-light, and it’s a 
pure sum. Or define a type with just one value constructor, as in pair, and it’s a 
pure product. le S 
Because algebraic data types can express sums, products, and recursion, they Ve es pie 
BTEMPTY 463d 
are technically universal. But they are also universal in a more important, less BTNODE 463d 
technical sense: sums of products turn out to be a great model for data structures. preorder-elems 
For example, a linked list is a sum of products. So is a binary tree. So are the ge 
abstract-syntax trees found throughout this book. A sum of products is something 
that every programmer must know how to code, in any language. As examples, 
I discuss two languages or language families: C, the language of Chapters 1 to 4 
(and also of the world’s computing infrastructure), and object-oriented languages, 
a popular and maybe even dominant language family for over 20 years. 
In C, a general sum of products is awkward to code. C’s union type implements 
a sum, but a value of union type doesn’t record which choice is represented—that 


1If you are wondering about the names, pick some finite types like bool and traffic-light, then 
count the number of values that inhabit a sum like “Boolean or light” or a product like “Boolean and 
light.” And note that “product” is the Cartesian product, which you may have studied in math class. 
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information has to be stored in a tag off to the side. In the general case, a sum of 
products is therefore a struct containing both a tag and a union of structs. But there 
is an important and common special case: a sum with only two forms, only one of 
which carries a product. In that case, the sum of products can be represented by a 
pointer: 


* The form that carries a product is represented by a pointer to a struct con- 
taining the product, which is usually allocated on the heap. 


* The form that does not carry a product is represented by the NULL pointer. 


This representation works nicely for lists, binary trees, and things like option. 
In particular, it supports a simple, efficient test to identify the form of the data: 
ask if a pointer is NULL. 

In object-oriented languages (Chapter 10), a sum of products emerges when- 
ever different forms of objects work together to implement the same abstraction. 
Each individual object is a product: the product of the values of all its instance vari- 
ables (sometimes called members or fields). And a collection of related objects is 
a sum of those products, referred to by the conventions of a particular language. 
For example, in Smalltalk, that collection would be a set of objects that respond to 
the same protocol; in Java, a set of objects that implement the same interface; and 
in C++, a set of objects whose classes inherit from the same superclass. 

With these universal ideas in mind, we’re ready to study algebraic data types 
in the context of a complete programming language: WML. A programmer's view 
encompasses an informal description of type definitions, case expressions, and 
pattern matching, with examples; equational reasoning with algebraic data types, 
and the extension of pattern matching to other language constructs. A theorist’s 
view encompasses generativity and its effect on type equivalence; a theory of user- 
defined types; and a theory of case expressions. 


8.2 ALGEBRAIC DATA TYPES IN £.ML 


Algebraic data types combine nicely with nano-ML; the resulting language is 
called ML. jsML’s concrete syntax is shown in Figure 8.1 on the facing page. The 
syntax includes not only the case-expression and data-definition forms, but also 
three syntactic categories not found in nano-ML: patterns, kinds, and type expres- 
sions. 


* Patterns are used in case expressions. A case expression is evaluated as 
shown by example above, as explained informally just below, and as spec- 
ified formally in Section 8.8. 


* Types and kinds are used data definitions. The only truly new definition form 
is data; the implicit-data and record forms are syntactic sugar for data. 
Unlike the definition and expression forms in nano-ML, which do not men- 
tion kinds or types, the data definition specifies both kind and type-exp, using 
the same syntax as Typed wScheme. 


Figure 8.1 hints at a syntactic distinction, or really a lexical distinction, that 
is not made in Typed Scheme or nano-ML: ssML’s term language uses two dis- 
joint sets of names. One set is used for value variables and the other for value 
constructors. The distinction parallels a distinction made in the type languages for 
Typed Scheme, nano-ML, and now pML, in which type variables are notated dif- 
ferently from type constructors. (The name of a type variable begins with an ASCII 
quote character, and the name of a type constructor doesn't.) In the term language 


def = 
* 


(val value-variable-name exp) 
(val pattern exp) 
(val-rec value-variable-name exp) 
exp 
(define function-name ( { value-variable-name} ) exp) 
(define* { [ (function-name { pattern} ) exp] } ) 
(data kind type-constructor-name { [value-constructor-name : type-exp] }) 
(implicit-data [[ { 1 type-variable-name} 1] type-constructor-name 
{ value-constructor-name [ value-constructor-name of type-exp] }) 
(record [c { ! type-variable-name} 1] record-name ( {Lfield-name : type-exp]} )) 
(use file-name) 
unit-test 


type-exp ::= type-constructor-name 


kind 


' type-variable-name 

(forall L{ ' type-variable-name} ] type-exp) 
[ { type-exp} -> type-exp] 

[type-exp { type-exp}] 

= * | ({kind} => kind) 


unit-test ::= (check-expect exp exp) 


exp 


choice 
pattern 


literal 
S-exp 


(check-assert exp) 

(check-error exp) 

(check-type exp type-exp) 
(check-principal-type exp type-exp) 
(check-type-error exp) 

::= literal 

value-variable-name | value-constructor-name 
(case exp { choice} ) 

(if exp exp exp) 

(begin {exp}) 

(exp { exp} ) 

¢ (1et | let* | letrec) c{ [ value-variable-name exp] } ) exp) 
(lambda ( { value-variable-name} ) exp) 

* ((let | let*) ({ [pattern exp]}) exp) 

* (lambda ({ pattern} ) exp) 

::== [pattern exp] 

::= value-variable-name 

value-constructor-name 
(value-constructor-name { pattern} ) 


= Aihion | 'S-exp | (quote S-exp) 
::= literal | symbol-name | ({S-exp}) 


numeral ::= token composed only of digits, possibly prefixed witha plus 


or minus sign 


value-constructor-name 


"= cons | me) | a token that begins with # or with a capital letter 
or with make- 


*name ::= token that is not a bracket, a numeral, a value-constructor- 


name, or one of the “reserved” words shown in typewriter 
font 


Figure 8.1: The concrete syntax of jML (x marks syntactic sugar) 
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of ML, it is the value constructor that is specially marked: after any preceding 
fragments that are separated with dots, the name of a value constructor begins 
with a capital latter or the hash character, and the name of a value variable doesn't. 
The details are presented in Section 8.2.2. 

Figure 8.1 shows only the syntax of ML, not its values. In addition to the sym- 
bols, numbers, and functions found in wScheme and nano-ML, ML provides just 
one other form of value: a constructed value. Constructed values represent not 
only values of algebraic data types defined by users, but also pairs, cons cells, NIL, 
and Booleans. By contrast, in nano-ML, pairs, lists, and Booleans each have their 
own special representations. The change may sound significant—and for a com- 
piler writer, type theorist, or semanticist, it is a welcome simplification—but as a 
programmer, you won't notice. 

The rest of this section describes the evaluation of case expressions, pattern 
matching, and data definitions. It also shows some of the code used to build WML’s 
initial basis. The chapter continues with equational reasoning (Section 8.3) and 
with popular syntactic sugar (Section 8.4), before wrapping up with theory topics 
(Sections 8.5, 8.7, and 8.8). 


8.2.1 Evaluation of pattern matching 


Given an environment p, an expression of the form (case e [p; €1]--- [Pn €n]) 
is evaluated by pattern matching. 


1. First e is evaluated in environment p to produce a value v (the scrutinee). 


2. Next v is checked against p1,..., Pn in turn, to identify the first p,; that 
matches.? Matching not only selects [p; e;]; it also produces a set of bind- 
ings p’ that are used to extend the environment p. Environment p’ includes 
a binding for every variable that appears in pattern p;. 


3. Finally e; is evaluated in an extended environment containing bindings from 
both p and p’. The value of e; becomes the value of the entire case expres- 
sion. 


Matching is defined by induction on the structure of a pattern: 


« A variable x matches any value v, and the match produces the singleton set 
of bindings {x +> v}. 


* A wildcard matches any value v, and the match produces no bindings. 


* A value constructor K matches a value v if and only ifv = K. That is, if 
v is the value constructor by itself, not applied to any arguments. The match 
produces no bindings. 


* Finally, when pattern p is a value constructor K applied to one or more sub- 
patterns, say p = (K p\---pi.,), this pattern matches value v if there are 
values U1,...,Um such that v = (K v1, --+Um), and for every i from 1 to k, 
pi, matches v;. The match produces the bindings obtained by taking the 
union of all sets of bindings produced by each of the sub-matches of p; to v;. 
To ensure that the union is well defined, variables appearing in sub-patterns 
must be distinct. 


Compilers for languages that use algebraic data types, including ML and Haskell, don’t actually try 
each pattern in sequence. Instead, they translate each case expression into an efficient automaton. 
Using such an automaton, the matching pattern is found cheaply; the cost is typically a few machine 
instructions times the maximum number of value constructors appearing in any one pattern. 


Table 8.2: Examples of pattern matching 


Pattern Value Result 
(cons x xs) '(123) Succeeds, p’ = {x 4 1,xs +> '(23)} 
(cons x2 xs) "(bc) Succeeds, 
pi = {x2 'b,xsh> '(c)} 
x1 'a Succeeds, p’ = {x1 +> 'a} 
(cons x1 (cons x2 xs)) '‘(abc) Succeeds, p’ = {x1+> 'a,x2+> 'b, 
xs +> '(c)} 
(cons x1 (cons xe xs)) "(a) Fails 
(cons x2 xs) "C) Fails 
(cons x '()) z@) Fails 
(cons x '()) "(a) Succeeds, p’ = {x +> 'a} 
(cons x '()) "(a b) Fails 
"C) "(a) Fails 
'() Zo) Succeeds, p' = {} 


A good simple example is a non-nested pattern (KK x, ---2,,,) matched against 
a value (K v,--+-Um); this match succeeds, and it produces the set of bindings 
{x1 > U1, ...; 2m 'O Um}. This kind of match corresponds to the first two 
example entries in Table 8.2. The fourth entry in the table uses a nested pat- 
tern: (cons x1 (cons x2 xs)) is matched against the value '(abc). The match- 
ing of the sub-patterns is shown in the previous two entries: Sub-pattern x1 is 
matched against value 'a and succeeds, producing binding {x1 +> 'a}. Sub- 
pattern (cons x2 xs) is matched against value '(bc) and succeeds, producing 
bindings {x2 +> 'b,xs +» '(c)}. So the whole match succeeds, producing bind- 
ings {x1 +> 'a,x2> 'b,xst> '(c)}. 

In the next entry, the same pattern (cons x1 (cons x2 xs) ) is matched against 
value '(a). The first sub-match succeeds, producing {x1 +> 'a}. But the sub- 
match of (cons x2 xs) against '() fails, because cons and '() are different value 
constructors. So the whole match fails. 


8.2.2 Distinguishing value constructors from variables 


As implemented in Standard ML, pattern matching has a pitfall: if you misspell the 
name of a value constructor, which matches only itself, Standard ML might take 
the misspelling for a value variable, which matches anything. If you’re lucky, you'll 
get a warning from the compiler, but whether you are warned or not, you'll get 
different behavior from what you intended. For example, given a list of lights, does 
this Standard ML code test to see if the first one is green? 
469. (pitfall in Standard ML 469)= 

datatype traffic_light = GREEN | YELLOW | RED 

val startsWithGreen : traffic_light list -> bool = 

fn lights => 
case lights 
of GREEEN :: _ => true 
— => false 


As shown on the next page, this code doesn’t do what you might think. 
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It seems that any list starts with GREEN: 


470a. (transcript of Standard ML using startsWithGreen 470a)= 
- startsWithGreen [GREEN, YELLOW, RED]; 
val it = true : bool 
- startsWithGreen [YELLOW, RED, GREEN]; 
val it = true : bool 


In the case expression on the previous page, I misspelled GREEN. The compiler 
parses GREEEN as a variable, so the first choice matches any nonempty list. And the 
compiler gives no warning, because the second case can also match: it matches the 
empty list. What’s called startsWithGreen is actually a “not null” function. 

This problem can be mitigated by using the wildcard pattern cautiously—for ex- 
ample, only as an argument to a value constructor. But the problem can be avoided 
entirely through better language design. Languages like OCaml, Haskell, and uML 
mandate a spelling convention: depending on the way a name is spelled, it can 
stand for a variable or for a value constructor, but never both. (Standard ML uses 
such a convention in the type language, but not in the term language.) sML’s con- 
vention, in order to preserve compatibility with nano-ML and ~Scheme, is more 
elaborate than most: 


« Ifaname contains a dot (.), every character up to and including the last dot is 
removed. If what’s left begins with a capital letter or with the # symbol, it’s the 
name of a value constructor; it cannot stand for a variable or function. 


* To enable us to write lists that look like jsScheme and nano-ML lists, the name 
cons and the syntax '() are both deemed to be value constructors. 


* For compatibility with the record form, any name beginning with make- is 
the name of a value constructor. 


+ Any other name is the name of a value variable, or simply a variable; it cannot 
stand for a value constructor. 


In “ML, the name GREEEN begins with a capital letter, so it must be the name of a 
value constructor. Since no value constructor by that name appears in the environ- 
ment, the following starts-with-green function, which has the same bug as the 
version above, is rejected by the type checker: 
470b. (transcript 459a) += 1465 470c> 
-> (val starts-with-green 
(lambda (lights) 
(case lights 
[(cons GREEEN _) #t] 
Le #f))) 
type error: no value constructor named GREEEN 
When the spelling is corrected, everything works as it should: 
470c. (transcript 459a) += <1470b 474d> 
starts-with-green : ((list traffic-light) -> bool) 


-> (val starts-with-green 
(lambda (lights) 
(case lights 

[(cons GREEN _) #t] 

= #f]))) 
starts-with-green : ((list traffic-light) -> bool) 
-> (starts-with-green (list3 GREEN YELLOW RED)) 
#t : bool 
-> (starts-with-green (list3 YELLOW RED GREEN)) 
#f : bool 


When you're working on interpreters written in Standard ML, beware of this 
pitfall. If you a see a strange error message about “redundant” pattern matches, or 
if your code produces senseless results, look for a misspelled value constructor. 


8.2.3 Typing and evaluation of datatype definitions 


In wML, as in Haskell, an algebraic data type may be defined in two ways. The 
data form gives the kind of the type constructor and the type of each of its value 
constructors. The implicit-data form leaves the kind of the type constructor to 
be inferred, and it gives only the argument types, if any, of each value constructor. 
Each form has advantages and disadvantages: 471 
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* Inthe data form, all types and kinds appear explicitly in the source code, so 
they are crystal clear. But to use the data form, you have to understand and 
follow the rules given below for the types of value constructors; if you break 
the rules, your definition will be rejected by the type checker. 


* Inthe implicit-data form, you have to follow only one rule: the argument 
type of each value constructor must be well kinded. But the types of the value 
constructors don’t appear in the source code; if you want to know them, you 
have to reconstruct them mentally. 


The data form supports some fancy extensions that are described in Appendix S, 
but the implicit-data form is easier to write, and it is isomorphic to the corre- 
sponding forms in Standard ML and OCaml. (Full Haskell supports both forms, 
including extensions; OCaml supports extensions by adding constraints to the 
implicit-data form.) 

A data form that defines algebraic data type T looks like this: 


(datak T [hy :t1]---([ Ky: tn), 


where & isa kind, T is the name of the type or type constructor being defined, each 
KK; is the name of a value constructor, and each t; is a type expression giving the 
type of that value constructor. To enable type inference to work, each t; must obey 
these rules: 


+ Every ¢; must be well kinded. Each type t; may use type name T’, but only in 
a way that is consistent with its kind x: If « is *, then T is a type all by itself, 
and it takes no parameters. If « has the form (*---* => *), then JT’ takes as 
many type parameters as there are stars to the left of the arrow. 


: If T takes type parameters, then each value constructor must be polymor- cons B 
phic, and in its type t;, the number of variables under the forall must be GREEN 459a 
equal the to number of type parameters T' is expecting. If 7’ takes no type es B 


‘ type traffic- 
parameters, each value constructor must be monomorphic. nant 459a 


For example, the traf fic-light type takes no parameters, and its value con- 
structors are monomorphic. But the option type takes a type parameter, so 
its value constructors SOME and NONE are polymorphic. 


* Underneath the forall, if any, each type ¢; has a result type, and that type 
must be valid. The result type is determined by the shape of the type under 
the forall: if itis a function type, the result type is the type to the right of 
the function arrow. Otherwise, the result type is whatever appears under 
the forall. Any given t; may or may not use forall, and it may or may not 
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be a function type, so there are four cases in total, as illustrated by these 


examples: 
Type Result type Validity 
traffic-light traffic-light Valid 
(forall ['a] (list 'a)) (list 'a) Valid 
(int -> speed) speed Valid 
(forall ['a] ('a-> (option 'a))) (option 'a) Valid 


A result type is valid if and only if it is T itself or it applies T to one or more 
distinct type variables. The four examples above have valid result types; here 
are two examples with invalid result types: 


Type Result type Validity 
(list int) (list int) Invalid 
(forall ['a] ('a-> (pair 'a'a)) (pair 'a 'a) Invalid 


These rules make type inference relatively straightforward. In more ambitious lan- 
guages, some of the rules can be relaxed—full languages like Haskell support not 
only standard algebraic data types but also generalized algebraic data types and ex- 
istential algebraic data types, as described in Appendix S—but relaxing the rules 
makes type inference more difficult. 

The rules are checked when a data definition is typed. If the rules are re- 
spected, type T' is added to the basis, where it stands for a unique type constructor 
of kind «, distinct from all other type constructors. The guarantee of distinction 
makes the definition generative. Each K;; is also added to the basis, to the type en- 
vironment with type ¢;, and to the value environment either as the bare constructed 
value K; or as an anonymous primitive function that applies K; to its arguments. 


The implicit-data form is described by this EBNF: 


def ::= (implicit-data [c{ : type-variable-name } 1] type-constructor-name 
value-constructor-name | [value-constructor-name of { type-exp }] }) 


The form includes optional type parameters, the name of the type constructor be- 
ing defined, and specifications of one or more value constructors. A value con- 
structor that takes no arguments is specified by its name. A value constructor that 
takes arguments is specified by its name, followed by the keyword of, followed by 
the types of its arguments, all wrapped in parentheses. Using metavariables, an 
example of the form looks like this: 


(implicit-data [tar tee Om] T 
Ky--+ Ky (Kggi of t---t] +++ [Kp of t-++t]) 


This implicit-data form requires less notation than the data form—for example, 
there is never an explicit forall—and it imposes just one rule: the ¢’s must be well 
kinded. The implicit-data form closely resembles the datatype form in Stan- 
dard ML, which is used to implement the interpreters in this book from Chapter 5 
onwards. 

When typed and evaluated, implicit-data does exactly what data does: itadds 
T to the basis, bound to a fresh type constructor, and it adds each K;. Each K;’s 
result type t, is either T alone, if there are no type parameters, or if there are type 
parameters, itis (T’ a, --: A). If K; is specified just by its name, its type is the 
result type t,; if KX; is specified using the form [K; of t; --- ty], then its type 


(implicit-data 7 (data * T 


ky [ky : T] 
7 " 5 
LA; of ty +++ th] [Ay : (ti +++ th -> T)] 
) ) §8.2 
Algebraic data 
(a) Without type parameters Dre te 
473 
(data (#1 +++ *, => *) T 
(implicit-data (a, --- Q,) T [ky : (forall (ay --: Am) 
ky (T ay +++ Am))I 
[kj of ty ++ tr] = [K; : (forall (a1 -+: Qm) 
(t1 +++ ty -> 
(T a1 +++ Gm)))I 
) 
) 
(b) With type parameters 
Figure 8.3: Desugaring implicit-data 
is the function type t; x --: xX tn — t,. In both cases, when type parameters are 


present, the type of each K; is turned into a polymorphic type scheme by using 
forall to close over them. 

Formally, implicit-data is syntactic sugar for data. It is desugared by one 
of two equations, depending on whether type parameters are present (Figure 8.3). 
When type parameters are absent, every value constructor gets a monomorphic 
type. When type parameters are present, every value constructor is polymorphic 
in exactly those parameters. Type name T’ is applied to the parameters and is given 
a kind consistent with them. In the interpreter, the desugaring is implemented by 
function makeExplicit (Appendix S, page S469). 


8.2.4 Predefined algebraic data types 


Many of the algebraic data types found in Standard ML are also predefined in ML. 
They are defined using data or implicit-data. In most cases, to make the types 
of the value constructors explicit, I use the data form. 
A Boolean is either #t or #f. 
473a. (predefined ML types 463a) += <1463a 473b> 
(data * bool 
[#t : bool] 
[#f : bool]) 
A list is made using either '() or cons. 
473b. (predefined .ML types 463a) += <1473a 474a> 
(data (* => *) list 
['O : (forall ['a] (list 'a))] 
[cons : (forall ['a] ('a (list 'a) -> (list 'a)))]) 


The unit type, which is the result type of print1n and print, is inhabited by 
the single value UNIT. 
474a. (predefined ML types 463a) += <1473b 474b> 
(data * unit [UNIT : unit]) 
Type pair is defined on page 464, with accompanying functions pair, fst, and 
snd. Types for triples and larger tuples are also predefined; the value constructor 
User-defined, for type triple is TRIPLE, and the value constructors for types 4-tuple through 
algebraic types (and 10-tuple are T4 to T10, respectively (Appendix S). These types are defined with- 
pattern matching) out any accompanying functions. If you want functions, define them using pattern 
matching. Or do Exercise 27 and match tuples directly in let forms. 
474 The order type is a standard result type for comparison functions. It represents 
a relation between elements of a totally ordered set: one element may be less than, 
equal to, or greater than another. 


474b. (predefined .ML types 463a) += 1474a 
(implicit-data order LESS EQUAL GREATER) 


This representation is used in the predefined function Int.compare: 


474c. (predefined ML functions 458) += <1464e 475a> 
(define Int.compare (n1 n2) Int.compare : (int int -> order) 
(if (< ni n2) LESS 
(if (< n2 ni) GREATER 
EQUAL) )) 


The order type is equally useful in user-defined functions: 
474d. (transcript 459a) += <1470c 474e> 


compare-speeds : (speed speed -> order) 


-> (define compare-speeds (speedi speed2) 
(if (speed< speedi speed2) 
LESS 
(if (speed< speed2 speedi) 
GREATER 
EQUAL) )) 


Because values of order type can be can be scrutinized in case expressions, 
using them often results in simpler code than using Booleans, which require nested 
if expressions. A nested if can implement a three-way comparison: 
474e. (transcript 459a) += 474d 474£> 

-> (define speed-opinion (s) speed-opinion : (speed -> sym) 
(if (speed< s (MPH 65)) 
'too-slow 
(if (speed< (MPH 65) s) 
'too-fast 
'just-right) )) 
-> (speed-opinion (KPH 110)) ; guide for Canadians in the US 
too-fast : sym 


But a pattern match on an order is simpler and clearer: 


474f. (transcript 459a) += <1474e 488a> 
-> (define speed-opinion-too (s) speed-opinion-too : (speed -> sym) 
(case (compare-speeds s (MPH 65)) 
[LESS 'too-slow] 


[GREATER 'too-fast] 
[EQUAL 'just-right])) 
-> (speed-opinion-too (KPH 110)) 
too-fast : sym 
-> (speed-opinion-too (MPH 65)) 
just-right : sym 


8.2.5 Pattern matching in predefined functions 


In Scheme and nano-ML, list values are built in, so the basic list functions must 
be built in as primitives. In jsML, the basic list functions are user-defined. 


475a. (predefined ML functions 458) += <1474c 475b> 
null? : (forall ['a] ((list 'a) -> bool)) 
(define null? (xs) car: (forall Ee Critst ies -> a) $8.2 
(case xs ['() #t] cdr : (forall ['a] ((list 'a) -> (list 'a))) Algeraie ata 
: eae a ett. types in UML 
(define car (xs) 
(case xs ['() Cerror 'car-of-empty-list)] 475 
[(cons y _) y])) 
(define cdr (xs) 
(case xs ['() Cerror 'cdr-of-empty-list) ] 
[(cons _ ys) ys])) 
Don’t get fond of nu11?, car, and cdr. These functions are rarely needed; most code 
uses pattern matching, as in these versions of append and revapp: 
475b. (predefined ML functions 458) += <1475a 475c> 
append : (forall ['a] ((list 'a) (list 'a) -> (list 'a))) 
revapp : (forall ['a] ((list 'a) (list 'a) -> (list 'a))) 
(define append (xs ys) 
(case xs 
['O ys] 
[(cons z zs) (cons z (append zs ys))])) 
(define revapp (xs ys) 
(case xs 
['O ys] 
[(cons z zs) (revapp zs (cons z ys))])) 
Function bind operates on association lists. The code uses only pattern match- 
ing, not nul1?, car, or cdr. I encourage you to compare it with the nano-ML version 
in chunk S423b. 
475c. (predefined ML functions 458) += <1475b 475d> 
bind: (forall ['a 'b] ('a 'b (list (pair 'a 'b)) -> (list (pair 'a 'b)))) 
(define list1 (x) (cons x '())) 
(define bind (x y alist) 
(case alist 
['() (listl (pair x y))] 
[(cons p ps) 
(if (= x (fst p)) EQUAL B 
(cons (pair x y) ps) GREATER B 
(cons p (bind x y ps)))])) LESS B 
Functions find and bound? also improve on their nano-ML versions. When a ies ee 


key is not found, find needn't call error; it can instead return a value of option 
type. Using nested patterns, find can be implemented without using fst or snd. 
475d. (predefined ML functions 458) += <1475¢ 476> 
find : (forall ['a 'b] ('a (list (pair 'a 'b)) -> (option 'b))) 
(define find (x alist) 
(case alist 
['O NONE] 
[Ccons (PAIR key value) pairs) 
(if (= x key) 
(SOME value) 
(find x pairs))])) 


In nano-ML, bound? must reimplement the same search algorithm used in 
find. But in zML, bound? simply calls find. 
476. (predefined {sML functions 458) += 475d 
bound? : (forall ['a 'b] ('a (list (pair 'a 'b)) -> bool)) 
(define bound? (x alist) 


(case (find x alist) 


User-defined, [(SOME _) #t] 
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pattern matching) The rest of the predefined functions are defined in Section S.2.4 (page $445). 
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8.3. EQUATIONAL REASONING WITH CASE EXPRESSIONS 


Like jsScheme and nano-ML, juML is a functional language. As such, it supports the 
same equational-reasoning techniques as jzScheme, and even the same algebraic 
laws (Section 2.5). But unlike pjScheme, zMLhas algebraic data types and case ex- 
pressions. And equational reasoning can be used on them, too. 


* Case expressions obey several useful laws. 


+ Laws involving constructed data can be proved by generalizing the inductive 
proof techniques that are used to prove facts about lists and S-expressions. 


The laws for case expressions follow from the rules for evaluating case expressions: 


* If its scrutinee matches the pattern in the first choice, a case expression is 
equivalent to a let expression. 


* If its scrutinee doesn’t match the pattern in the first choice, a case expression 
is equivalent to the same case expression with the first choice removed. 


If you can’t tell whether a scrutinee matches the pattern in a first choice, then you 
break your proof down by cases, adding one case for each value constructor in some 
algebraic data type. You can make it easy to tell by eliminating nested patterns. 
Matching of non-nested patterns is described by simple laws. 

Each law of matching applies to a case expression in which the first choice con- 
tains one particular form of pattern: variable, bare constructor, or constructor ap- 
plication. If its first pattern is a variable, a case expression is equivalent to a let 
expression. 


(case e [ve’]---) = (let ([xve]) e’) 


If its first pattern is a value constructor, and if the scrutinee is that same value con- 
structor, then a case expression is equivalent to the first right-hand side. 


(case K [K e’]---) =e’ 


If the first pattern applies a value constructor K, and if the scrutinee is constructed 
by applying i, then a case expression is equivalent to a let expression. 


(case (KK €, +++: En) 


— eee / 
CK ay oe ae) elon) = et (181 er] +++ [an end) e’) 


If the first pattern involves a value constructor, it might not match the scrutinee. 
In that event, the case expression is equivalent to a similar expression with the 
first choice removed. For example, when K 4 K’, 


Rey oe ep 
ree nan Si ae (case (K €1 +++ €n) 
[pe’]-+-) mt [pets s<J: 


Other laws you can work out for yourself. 
To show some case-expression laws at work, I prove two properties of the 
bt-map function, which is defined on the binary trees of Section 8.1 (page 463): 


(bt-map f BTEMPTY) = BTEMPTY 
(bt-map f (BTNODE x t1 t2)) = (BTNODE (f x) (bt-map f t1) (bt-map f t2)) 


Both properties are proved by appealing to the definition of bt-map; the proofs are 
shown in Figure 8.4. 

The first proof uses just the one case-expression law; the second proof uses two 
case-expression laws, plus laws that simplify let expressions. 

As these examples show, the laws for case expressions enable us to prove equal- 
ities involving particular constructed values. But to prove properties that hold for 
all values of a given type T, we need a proof principle for 7. When 7 is an algebraic 
data type, the proof principle requires only that we prove one case for each of 7’s 
value constructors. And if any value constructor takes an argument of type 7, that 
case can use an inductive hypothesis. 

As an example, I prove this “map-preorder” property: 


(preorder-elems (bt-map f t)) = (map f (preorder-elems t)) 


A property like this is sometimes expressed using a commutative diagram. Assum- 
ing that f has type (7 -> 7’), the diagram looks like this: 


bt-map f } 
(bt 7) ————+} (bt T’) 


preorder-elens | | precraer-eiens 


: map f : / 
(list 7) ——> (list7T) 


In a commutative diagram, any path between two points is supposed to be equiv- 
alent to any other path. In this case, the paths from upper left to lower right are 
equivalent, which is exactly the property I’m about to prove. 

To show how preorder-elems commutes with the map functions, I use these 
laws, the proof of which is left to you (Exercise 20): 


(preorder-elems BTEMPTY) = '() 
(preorder-elems (BTNODE x ti t2)) = (cons x (append (preorder-elems t1) 
(preorder-elems t2))) 


§8.3 
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(bt-map f BTEMPTY) 


User-defined = {substitute actual parameters in definition of bt-map } 
algebraic types (and (case BTEMPTY 
pattern matching) [BTEMPTY BTEMPTY] 
478 [(BTNODE a left right) (BTNODE (f a) (bt-map f left) (bt-map f right))]) 


= {first choice matches, with no bindings} 
BTEMPTY 


(a) The first law: bt-map applied to an empty tree 


(bt-map f (BTNODE x t1 te2)) 
= {substitute actual parameters in definition of bt-map } 
(case (BTNODE x t1 t2) 
[BTEMPTY BTEMPTY] 
[(BTNODE a left right) (BTNODE (f a) (bt-map f left) (bt-map f right))1) 
= {first choice doesn’t match} 
(case (BTNODE x t1 t2) 
[(BTNODE a left right) (BTNODE (f a) (bt-map f left) (bt-map f right))]) 
= {first choice matches, with bindings} 
(let ([a x] 
[left t1] 
[right t2]) 
(BTNODE (f a) (bt-map f left) (bt-map f right))) 
= {substitute x for a and drop binding } 
(let ([left t1] 
[right te]) 
(BTINODE (f x) (bt-map f left) (bt-map f right))) 
= {substitute t1 for left and drop binding} 
(let ([right t2]) 
(BTNODE (f x) (bt-map f t1) (bt-map f right))) 
= {substitute t2 for right and drop binding} 
(let ©) 
(BTINODE (f x) (bt-map f t1) (bt-map f t2))) 
= {simplify empty let} 
(BTNODE (f x) (bt-map f t1) (bt-map f t2)) 


(b) The second law: bt-map applied to a nonempty tree 


Figure 8.4: Proofs of the basic bt-map laws 


To prove that the map-preorder property holds for any tree t, I need consider 
only two cases: tree t is made either with BTEMPTY or with BTNODE. The case of the 
empty t is easy: 


(preorder-elems (bt-map f t)) 


= {assumption that t is empty} $8.3 
(preorder-elems (bt-map f BTEMPTY)) Equational 
= {first bt-map law} reasoning with 
(preorder-elems BTEMPTY) case expressions 
= {first preorder-elems law} 479 


me) 
= {map-empty law} 
(map f '()) 
= {first preorder-elems law} 
(map f (preorder-elems BTEMPTY) ) 
= {assumption that t is empty} 
(map f (preorder-elems t)) 


The case of anonempty t requires induction. Iassume that t is (BTNODE x t1 t2), 
and I use the inductive hypothesis on subtrees t1 and te: 


(preorder-elems (bt-map f t)) 
= {assumption that t is (BTNODE x t1 t2)} 
(preorder-elems (bt-map f (BTNODE x ti t2))) 
= {second bt-map law} 
(preorder-elems (BTNODE (f x) (bt-map f t1) (bt-map f t2))) 
= {second preorder-elems law} 
(cons (f x) (append (preorder-elems (bt-map f t1)) (preorder-elems (bt-map f t2)))) 
= {inductive hypothesis applied to t1} 
(cons (f x) (append (map f (preorder-elems t1)) (preorder-elems (bt-map f t2)))) 
= {inductive hypothesis applied to t2} 
(cons (f x) (append (map f (preorder-elems t1)) (map f (preorder-elems t2)))) 
= {map-append law from Chapter 2} 
(cons (f x) (map f (append (preorder-elems t1) (preorder-elems t2)))) 
= {cons-map law} 
(map f (cons x (append (preorder-elems t1) (preorder-elems t2)))) 
= {second preorder-elems law} 
(map f (preorder-elems (BINODE x ti t2))) 
= {assumption that t is (BTNODE x t1 t2) } 
(map f (preorder-elems t)) 


More proofs can be found in the Exercises. 
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8.4 SYNTACTIC SUGAR: PATTERNS EVERYWHERE 


Officially, .ML’s patterns appear only in case expressions. But in real languages, 
patterns aren't just for case expressions; patterns are used anywhere variables are 
bound, including lambda, let, let*, define, and val. In pML, thanks to syn- 
tactic sugar, patterns can appear in all these places as well. Such patterns are 
rewritten into case expressions; the rewrite rules, which you can implement (Ex- 
ercises 23 to 28), are described below. 

A pattern may appear as the single argument to a lambda expression. Such a 
pattern is most useful when the argument is a pair or a triple or something else 
with just one value constructor: 
480a. (patterns-everywhere transcript 480a) = 480b > 

-> (lambda ((PAIR x _)) x) 
<function> : (forall ['a 'b] ((pair 'a 'b) -> 'a)) 
-> (lambda ((PAIR _ y)) y) 
<function> : (forall ['a 'b] ((pair 'a 'b) -> 'b)) 


A single-argument lambda is desugared as follows: 
(lambda (p) e) = (lambda (7) (case x [pe])), where x ¢ fv(e). 


Variable x must not be a free variable of e, lest e’s meaning by changed by variable 
capture (Section 2.13.3, page 165). 

Patterns may also appear in a lambda abstraction that has multiple arguments. 
Such a lambda is desugared using a trick: its arguments are bundled into a tuple: 


(lambda (pi +++ Pn) e) = 
(lambda (21 +--+ Yn) (case (TNX +++ Xn) [(TN py +--+ Pn) e])), 


where for 1 <i < n, x; ¢ fv(e). The value constructor Tn is PAIR when n = 2, 
TRIPLE when n = 3, and T4 through T10 when 4 < n < 10 (chunk S441a). 
Value constructor Tn is used in two different syntactic forms that look identical: 
in the scrutinee of the case expression, (Tn 21 --- ,) is an expression, but in 
the choice, (Tn pi --- py) isa pattern. 

The desugaring transformation for lambda also works for define: 


(define f (p1 --- Pn) €) = 
(define f (a1 --+ @p) (case (Tn zy +++ Xp) [(Tn py ++ Pn) €1)). 


But for function definitions, a far more interesting transformation is available: 
a function can be defined using a sequence of clauses, each of which resembles an 
equation—an algebraic law. Such a clausal definition is desugared into an ordinary 
function definition that uses a case expression. 

In wML, a clausal definition begins with the keyword define* and continues 
with a sequence of clauses, each of which specifies an equation that is true of the 
function being defined. A clause’s left-hand side applies the function to a list of pat- 
terns; its right-hand side specifies what that application is equal to. As an example, 
a clausal definition of the standard length function has two clauses: 


480b. (patterns-everywhere transcript 480a) += <1480a 48la> 
-> (define* length : (forall ['a] ((list 'a) -> int)) 
[length '()) 0] 


[(length (cons x xs)) (+ 1 (length xs))]) 
length : (forall ['a] ((list 'a) -> int)) 
-> (length '(a b c)) 
3: int 


Function change-light from the beginning of this chapter can be defined using 
three clauses: 


481a. (patterns-everywhere transcript 480a) += <1480b 481b> 


(traffic-light -> traffic-light) 


-> (define* change-light : 


[(change-light GREEN) YELLOW] 
[(change-light YELLOW) RED] 
[(change-light RED) GREEN]) 
change-light : (traffic-light -> traffic-light) 
The define* form can also be used to define a function that takes multiple argu- 
ments, as in this clausal definition of legal-speed?. 


481b. (patterns-everywhere transcript 480a) += <1481a 481c> 


legal-speed? : (speed (option speed) -> bool) 


-> (define* 


[(legal-speed? my-speed (SOME limit)) (not (speed< limit my-speed)) ] 
[(legal-speed? my-speed NONE) #t]) 
legal-speed? : (speed (option speed) -> bool) 
As another example, same-length, which compares the lengths of two lists, uses 
more interesting patterns: 
481c. (patterns-everywhere transcript 480a) += <1481b 481d> 
-> (define* same-length? : (forall ['a 'b] ((list 'a) (list 'b) -> bool)) 


[(same-length? '() 'O) #t] 
[(same-length? (cons _ xs) (cons _ ys)) (Same-length? xs ys)] 
[(same-length? _ _) #f]) 


same-length? : (forall ['a 'b] ((list 'a) (list 'b) -> bool)) 


All these definitions are desugared using the same rule. A clausal definition 
defines function f using / clauses, and in each clause, f is applied to n patterns: 


(define* (define f (21 --- 2p) 
[Cf Pi +++ Pin) €1] (case (Tn 2% +++ Ln) 
[Cf pai ++: Pan) €2] [C1 pi +++ Pin) €1] 
: i [(1n p21 °** Pan) €2] 
[Cf Pk <** Pkn) 4) 
[QTM pra +++ Pkn) €k1)); 
where none of %1,...,%», appears free in any expression €;. 


An anonymous function can be defined clausally using lambda*; as an example, 
I define a function that splits a list into two halves (Section E.2). It uses an internal 
function (scan ir ys), which, when possible, transfers an element from r to jand 
drops two elements from ys, then continues. When ys or r is exhausted, scan 
returns the pair (1,1). Aletrec with a clausal lambda* is much simpler than nested 
case expressions (chunk S130a): 
481d. (patterns-everywhere transcript 480a) += <1481¢c 482a> 
halves : (forall ['a] ((list 'a) -> (pair (list 'a) (list 'a)))) 


-> (define halves (xs) 
(letrec 
({scan 
(lambda* 
[Cleft (cons w ws) (cons _ (cons _ zs))) 
(scan (cons w left) ws zs)] 
[QleftA right _) (pair (reverse left‘) right)])]) 
(scan '() xs xs))) 


§8.4 
Syntactic sugar: 
Patterns 
everywhere 
481 
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RED 459a 
reverse B 
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The halves function does indeed split a list into two halves: 
482a. (patterns-everywhere transcript 480a) += <481d 482b> 
-> (halves '(1 2 3 4 5)) 
(PAIR (1 2) (3 4.5)) : (pair (list int) (list int)) 
-> (halves '(1 2 3 4)) 
(PAIR (1 2) (3 4)) : (pair (list int) (list int)) 
-> (halves '()) 
(PAIR () ()) : (forall ['a] (pair (list 'a) (list 'a))) 


A lambda* is desugared in the same way as a define*: 


(lambda* (lambda (2X1 ++: Xn) 
[(P11 °** Piyn) €1] (case (TN X1 +++ Lp) 
[(p21 -** Pan) €2] [Cm Pia -** Pin) €1] 


o [(Tn p21 +++ Pan) €2] 


[(Pk1 °°’ Pkyn) €k]) : 
[(1 Pk +++ Pkyn) €k])). 


Finally, patterns may appear in let expressions. The let expression has the 
most complex desugaring rule, because the desugaring must ensure that every 
free variable of every pattern may have its type generalized into a polymorphic 
type scheme. Suppose a let expression binds pattern p,, which has free variables 
Y1,--+,Yn- The idea of the desugaring transformation is to move p; from the let 
into acase. A simple transformation almost works: 


(let ([pi €1] [p2 €2]...) €) # (let (£21 €1] [p2 e2]...) (case x1 [pi €1)), 


where x; ¢ fv(e). This transformation works whenever every free variable of 
pattern p, is used only with a monomorphic type scheme. Butit fails if free variable 
of p; is used polymorphically, as f is here: 
482b. (patterns-everywhere transcript 480a) += <1482a 482c> 
-> (let ({CPAIR f n) (pair (lambda (x) x) 73)]) 
(TRIPLE (f n) (f f) (f #t))) 
(TRIPLE 73 <function> #t) : (forall ['a] (triple int ('a -> 'a) bool)) 
If this code is desugared directly to a single case, the result doesn’t typecheck: 
482c. (patterns-everywhere transcript 480a) += <1482b 482d> 
-> (let ([x_1 (pair (lambda (x) x) 73)]) 
(case x_1 [(PAIR f n) 
(TRIPLE (f n) (f fF) (fF #t))])) 
type error: cannot make int equal to (int -> int) 
For f to be used polymorphically, it must be bound by a let, not by a case. The 
example let should be desugared like this: 
482d. (patterns-everywhere transcript 480a) += <1482c 483a> 
-> (let ({[x_1 (pair (lambda (x) x) 73)]) 
(let ([f (case x_1 ((PAIR f n) f))] 
[n (case x_1 ((PAIR f n) n))]) 
(TRIPLE (f n) (f f) Cf #t)))) 
(TRIPLE 73 <function> #t) : (forall ['a] (triple int ('a -> 'a) bool)) 

In a general let expression, each pattern-expression pair [p; e;] is desugared 
independently. If pattern p; is a variable, it is left alone. If p; is a wildcard, it is 
converted to a new variable x that is not free in e. And if p; is a constructor appli- 
cation that binds variables y1,..., Yn, the let expression is rewritten to wrap its 
body e in a let expression that binds all the variables y1,..., yn: 


(let (-++ [pj e;] +++) €) = (let (-++ [aj ej] +++) 
(let (--- [y; (case x; [p; yy ])1---) €)), 


where 7; is not free in e. This rewriting continues until all the let forms bind only 
variables, not other patterns. 


A caution: because the desugaring transformation converts a non-nested let 
into nested lets, patterns p; have to be checked for duplicate variables before desug- 
aring begins, as in this example: 
483a. (patterns-everywhere transcript 480a) += <1482d 483bp> 
-> (let ([(PAIR x y) (pair 3 4)] [(PAIR y z) (pair 7 8)]) (+ x (+ y z))) 
syntax error: bound name y appears twice in let $8.5 
Patterns are also useful in the val form. The val form is closely related to let, Type generativity 
and if it could be desugared using the same tricks, life would be good. Unfortu- and type 
nately, what corresponds to “an x; not free in e” is “an x; not used in the rest of equivalence 
the program.” But the desugaring transformation can’t know what x;’s might be 
used in the rest of the program. The best it can do is just pick a name, which, once 
bound, sits in the basis from then on. A reasonable name is it: 
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(val pe) = (val it e) 


(val y; (case it [p yi ])) 


This expansion does evaluate e exactly once, and it does bind each y; with the cor- 
rect, generalized type scheme. But it clobbers the variable it. 
483b. (patterns-everywhere transcript 480a) += <1483a 
-> (val (PAIR left right) (halves '(a bc d))) 
(PAIR (a b) (ec d)) : (pair (list sym) (list sym)) 
(c d) : (list sym) 
(a b) : (list sym) 
-> left 
(a b) : (list sym) 
-> right 
(c d) : (list sym) 

The syntactic sugar completes what you need to know in order to program ef- 
fectively using algebraic data types. To understand more deeply how they work, 
consult the theory and code in the next sections: when and how a user-defined 
type is distinct from similar types (Section 8.5), how the relevant syntax and values 
are represented (Section 8.6), how type definitions are typed and evaluated (Sec- 
tion 8.7), and how case expressions are typechecked and evaluated (Section 8.8). 


8.5 TYPE GENERATIVITY AND TYPE EQUIVALENCE 


In any language that has user-defined types, a programmer has to know if and when 
the types they define are equivalent to anything else. That knowledge is determined 
by the ways the language uses three concepts: structural equivalence, generativity, Healers 481d 


eon PAIR B 
and type abbreviation. one B 


* Structural equivalence says two types are equivalent when they are applica- 
tions of equivalent type constructors to equivalent type arguments, as in 
Typed uScheme’s EQUIVAPPLICATIONS rule (page 369): 


7% =T]1,1<i<n T=T 
(EQUIVAPPLICATIONS) 


(T1,--+)T) T= (11---y Th) T 


In #sML, as in Typed wScheme and nano-ML, structural equivalence is used 
for list types, function types, pair types, and so on. In C, structural equiv- 
alence is used for pointer types and array types; for example, pointers to 
equivalent types are equivalent. And in Modula-3, for example, structural 
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equivalence is used for record types: record types with the same fields are 
equivalent, provided that corresponding fields have equivalent types. 


Generativity is a property that a language designer can associate with any 
syntactic form involving types. If a syntactic form is generative, then a type 
or type constructor introduced by that form is distinct from—that is, not 
equivalent to—any other type or type constructor. In Typed Scheme and 
nano-ML, no forms are generative, because Typed jzScheme and nano-ML 
have no type-definition forms. In WML, the data and implicit-data forms 
are generative, as are the corresponding forms in Standard ML, OCaml, and 
Haskell. jsML’s record form is syntactic sugar for data, so it is generative, 
but the corresponding form in Standard ML is not. In C, the struct, union, 
and enum type definition forms—the ones that include fields in curly braces— 
are generative, but the corresponding type reference forms, like just plain 
struct Exp, are not (Exercise 29). In Haskell, both data and newtype defi- 
nition forms are generative; newtype introduces a new, distinct type that has 
the same run-time representation as an existing type. 


* A type abbreviation introduces a new name for an existing type. A type- 
abbreviation form is purposefully not generative; the new name is equiva- 
lent to the original type. In Molecule (Chapter 9), as well as Standard ML, 
type abbreviations are written using the type keyword; the same form ap- 
pears in Haskell, where it is called a type synonym, and in C, where it is called 
a “typedef declaration.” 


By design, only structural equivalence and generativity are used in (sML; type ab- 
breviations are added in Exercise 32. 

Generativity is a powerful idea, but in older work, especially work oriented to- 
ward compilers, you may see the term “name equivalence” or “occurrence equiv- 
alence.” These terms refer to special applications of generativity—for example, 
“name equivalence” may describe a language that has a syntactic form which re- 
sembles a type abbreviation but is generative. The terms “name equivalence” and 
“occurrence equivalence” usually describe language designs that were popular in 
the 1970s, but these terms are outmoded and should no longer be used. The con- 
cept of generativity is more flexible and can be applied to more designs. 

Of what use is generativity? Generativity helps ensure that two types are equiv- 
alent only when you mean them to be equivalent. This issue matters most when 
programs are split into multiple modules (Chapter 9). For example, if two record 
types both have numeric fields heading and distance, but one is degrees and miles 
and the other is radians and kilometers, you want them not to be equivalent. 

Generativity should inform our thinking about design, theory, and implemen- 
tation of programming languages. 


* The effect of typing a generative construct can be expressed by the idea of a 
“fresh” or “distinct” type constructor. To define freshness, jsML’s type theory 
remembers a set containing every type constructor ever created; a fresh con- 
structor is one not in that set. In the implementation, there’s less bookkeep- 
ing; each new type constructor is assigned an identity that is guaranteed to be 
unique. The techniques used are the same techniques used to allocate fresh 
locations in the operational semantics and implementation of Scheme. 


* When definitions can be generative and type names can be redefined, a sin- 
gle name can stand for different types in different parts of a program. In this 
way, a type name is like a variable name, which can stand for different values 
in different parts of a program. 


In the interpreter, types are represented in two ways. Type syntax, repre- 
sented by ML type tyex (chunk S454c) and shown mathematically as t, ap- 
pears in programs, and type syntax is built up using type names (ML type 
name). Types themselves, represented by ML types ty and type_scheme 
(chunk 408) and shown mathematically as 7 and o, are used by the type 
checker, and types are built up using type constructors (ML type tycon). 


The internal representation of type constructors, the generation of fresh type con- 98.6 
structors, and a type-equivalence function are presented below. Abstract syntax 

and values of |1ML 
8.5.1 Representing and generating type constructors 485 


The representation of a type constructor must solve two problems: it should be easy 
to create a type constructor that is distinct from all others, and it should be easy to 
tell if two type constructors are the same. I address both problems by assigning 
each type constructor an identity, which I represent by an integer. 
485a. (foundational definitions for generated type constructors 485a) = (S438d) 485bD> 
type tycon_identity = int 
Integers are great for algorithms but not so good for talking to programmers. 
To make it possible to print an informative representation of any type, I represent 
a type constructor as a record containing not only its identity but also a name used 
to print it. 
485b. (foundational definitions for generated type constructors 485a) += — (S438d) 4485a 485¢> 
type tycon = { printName : name, identity : tycon_identity 3 
Every type constructor is created by function freshTycon, which is defined in 
Appendix S. This function takes a type name as its argument and returns a tycon 
with a distinct printName and a unique identity. Type constructors are equal if 
and only if they have the same identity. 
485c. (foundational definitions for generated type constructors 485a) += (S438d) <1485b 
eqlycon : tycon * tycon -> bool 


fun eqTycon ( { identity = id, printName = _ 3 
, { identity = id', printName _s= 


id = id' 
With eqTycon defined, type equivalence is determined by function eqType, which 
is carried over unchanged from chunk 412a in Chapter 7. 
Generativity is implemented by calling freshTycon whenever a generative type 
definition is typed. Definitions of primitive types are also considered generative, 
and their type constructors are also created using freshTycon. 


485d. (type constructors built into 4ML and jHaskell 485d) = (S438d) 
val inttycon = freshTycon "int" 
val symtycon = freshTycon "sym" 


freshTycon S449b 
type name 303 


8.6 ABSTRACT SYNTAX AND VALUES OF UML 


User-defined, algebraic data types require new syntactic forms, which are shown 
in Figure 8.5: 


+ A DATA definition form defines a type. 


+ A VCONX expression form introduces constructed data, and a CASE expres- 
sion observes it. (In an expression, a value constructor VCONX has the same 
type theory and operational semantics as a value variable VAR, but as noted 
in Section 8.2.2 [page 469], a VCONX and a VAR are written differently in the 
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486a. (definition of def for zML 486a)= (S437b) 
datatype def = DATA of data_def type data_def 

| (forms of def carried over from nano-ML $438b) 

withtype data_def = name * kind * (vcon * tyex) list 


486b. (definitions of exp and value for {sML 486b)= (S437b) 486d > 
type vcon = name (* a value constructor *) 
datatype exp 
= VCONX of vcon 
| CASE of exp * (pat * exp) list 
| (forms of exp carried over from nano-ML $438a) 


Case expressions include patterns. 


486c. (definition of pat, for patterns 486c)= (S437b) 
datatype pat = WILDCARD 
| PVAR of name 


| CONPAT of vcon * pat list 


486d. (definitions of exp and value for 4ML 486b) += (S437b) <486b 
and value 
= CONVAL of vcon * value list 
| SYM of name 
| NUM of int 
| CLOSURE of lambda * value env ref 
| PRIMITIVE of primop 
withtype lambda = name list * exp 
and primop = value list -> value 


Figure 8.5: Key elements of sML’s abstract syntax and values 


source code—and they play different roles in patterns. They are represented 
differently in expressions, as well; that way, if a name is not found, the 
error message can clarify what the interpreter was expecting, as shown in 
chunk S452c.) 


Constructed data requires a representation, which in jsML is formed with CONVAL 
(Figure 8.5, bottom). 

Values formed with CONVAL replace some forms of value that are used in 
nano-ML. Nano-ML’s BOOLV form is no longer needed; in jzML, #t and #f are de- 
fined using a data definition, as value constructors of type bool. So for example, 
#t is represented by CONVAL ("#t", []), not by the BOOLV true used in nano-ML. 
Similarly, nano-ML forms NIL and PAIR are no longer needed: value construc- 
tors '() and cons are also defined using a data definition. sML’s values include 
only constructed data, symbols, numbers, and functions—a welcome simplifica- 
tion.? 

The DATA definition and the CONVAL value are explained below, in Section 8.7. 
The CASE expression and associated patterns are explained in Section 8.8. 


8.7. THEORY AND IMPLEMENTATION OF USER-DEFINED TYPES 


New type constructors are created by type definitions. And in any language with 
user-defined types, type definitions introduce new names, which have to be ac- 


3Nano-ML’s internal language could be simplified even more by eliminating the IFX syntax; if could 
be syntactic sugar for case. But to enable jzML’s interpreter to share code with nano-ML’s interpreter, 
I have kept both forms. 


counted for in the type theory. And if type constructors and type names are dis- 
tinct, type constructors must also be accounted for. In (4ML’s type theory, the ac- 
counting works like this: 


+ Each type name and type variable has a kind and stands for a type. The kind 
and the type are associated with the name in a kind environment A, which 
is part of wML’s basis. A is extended by each data definition, which adds a $8.7 


binding for the name of the defined type. Theory and 
implementation of 


LtML’s basis also includes a type-constructor set M, which contains the set of user-defined types 
all type constructors ever created. A type constructor created by a data def- 
inition must not be a member of /; that requirement makes the data form 
generative. Once created, each new type constructor is added to M. In the 
code, set / is represented by the mutable variable nextIdentity, which is 
used by freshTycon to ensure that each type constructor has a unique iden- 
tity (chunk S449b). I is the set given by this equation: 
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M={i|0<1i< !nextIdentity}. 


In addition to A and M, the basis of ML also includes a type environment I’. Asin 
nano-ML, I gives a type scheme for each value, and I is extended by val, val-rec, 
and define. In wML, I is also extended by data: a data definition adds one value 
binding for each value constructor. 

When a /sML definition is typed, any part of the basis may change. The judg- 
ment form is therefore | (d,T, A, M) — (I’, A’, M’) |. Rules for this judgment 
form rely on the following other judgment forms: 


Form Informal meaning 


(d,T) +I’ Nano-ML definition d is typed (new value) 

(d,T,A,M) > (I’, A’, M’) — uML definition d is typed (new value/type) 

OX MEK Type scheme o works for a value constructor of 
type pu 

AFtwo:* Type syntax t is translated to type scheme o 


The third judgment is a compatibility judgment o = js :: K; it says “type scheme 7 
can be the type of a value constructor for algebraic data type j1, which has kind k.” 
It is discussed in detail below. 


8.7.1 Typing datatype definitions using type compatibility 


In sML’s data form, the type of every value constructor is explicit in the syntax. type ie ae 
The type of each value constructor must be compatible with the new type that is ee pa ee 
being defined; for example, a value constructor of type int is not compatible with type tyex  $454c 
a definition of type bool. Compatibility is enforced by the o; = yz :: & premises in 


this rule: 


peM M=MUuU{u} 
A’ = A{T & (pu, 4)} 

NF wok, l<i<n 
O,Xpuk, l<i<n 

IY =T{ky :01,..., Kn: on} 


D 
(Data(T =: &, Ki :t),...,Kn:t,),F,A,M) = (1A, M4 (DATA) 


The Data rule is interpreted operationally as follows: 


1. Create a fresh type constructor j1, and record in the kind environment that 
type name T stands for type js with kind k. 


2. For each value constructor K; with given type t;, confirm that type t; has 
kind *, and translate it into an internal type scheme o;. This operation, ex- 


User-defined, pressed by judgment A’ + t; ~» 0; :: *, extends Typed psScheme’s judgment 
algebraic types (and A’ t; :: x, which merely checks that the programmer's type syntax is well 
pattern matching) kinded. It is described below. 

488 3. Also for each value constructor, check that its type scheme is compatible with 


the new type being defined (0; = ju :: kK). 


4, Finally, assuming that all the types are compatible, enter the types of the 
value constructors into the type environment. 


The compatibility judgment o = yu :: & says that a value constructor for type ju 
had better bea ju or returna js. As an example, I define type fish with two compat- 
ible value constructors and one incompatible one: 


488a. (transcript 459a) += <1474f 488b> 
-> (data * fish 
[BLUEGILL : fish] ; OK, you're a fish 
[BASS : (sym -> fish) ] ; OK, you return a fish 
[PISCES : sym] ; No good! A symbol is not a fish 
) 


type error: value constructor PISCES should have type fish, but it has type sym 


Since PISCES has an incompatible type, the definition is rejected. Eliminate PISCES 
and the definition is good:* 


48sb. (transcript 459a) += <1488a 493c> 
-> (data * fish 
[BLUEGILL : fish] ; OK, you're a fish 
[BASS : (sym -> fish) ] ; OK, you return a fish 
) 
-> BLUEGILL 


BLUEGILL : fish@gez 

-> (BASS 'largemouth) 

(BASS largemouth) : fishe@f{2z 
-> (BASS 'striped) 

(BASS striped) : fish@fg23 


A monomorphic value constructor is compatible if it is a fish or it returns a fish. 
A polymorphic constructor is the same, but with more fiddly detail: 


MONOISCOMPAT MONORETURNSCOMPAT 
oR Pk ——_—_. 
WX bik TM Xt XT OPS pi * 
POLYISCOMPAT 
a... , a4, all distinct 
/ / 
VO, . ++, Qp-(04,...,0,) eX i x1 ct KE > 
POLYRETURNSCOMPAT 
a,.--, Q, all distinct 
i. / 
VO1,. +5 Qe-T1 XX Ty > (Q4,---, 0g) WX i ky Re > 


4Because every data generates a fresh type contructor, the new type prints as fish@{23, which dis- 
tinguishes it from the original, bad fish. 


KINDINTROCON 


TéedomA A(T) =(r7,4) 
AkFterik 
AFT etik 
KINDAPP 
KINDINTROVAR AFte ti ky X+++X Kn KR 
a €domA A(a) = (7, &) AF Ve TuKj, 1<i<n 
AkFavtik AF C(t ty +++ tn) ~ (11,257) THK 
KINDFUNCTION 
AF Ve iu, l<i<n Akt tix 
AFtwo:* 
AF (ty +++ th > 1) TT] X08 XT OT 
SCHEMEKINDALL 
Q1,.-., Qn are all distinct SCHEMEKINDMONOTYPE 
Afay ++ (a1, *),..-,An > (Qn, *) fF te ri AFtmtiu 
AF (forall (a1 +++ Qn) t) ~ Vay,...,Qn.T 1 * AFteEviriu 


Figure 8.6: Translation of j:ML’s type syntax, with kinds 


The type variables a,...,a/,, which are the parameters to 1, are actually a per- 
mutation of the quantified type variables a1,..., a. But in the compatibility judg- 
ment, it’s enough for the a/’s to be distinct. If they are, the translation judgment 
A’ t; ~+ 0; :: * (below) ensures that they are a permutation of the a,,’s. 

The compatibility rules are implemented by function validate in Appendix S. 
Using that function, and using function txTyScheme to implement the translation 
judgment described below, function typeDataDef types a data definition. It re- 
turns I’, A’, and a list of strings: the name T followed by names [Ky,..., Ky]. 


489. (typing and evaluation of data definitions 489) = (S437a) 490 > 
typeDataDef : data_def * type_env * (ty * kind) env 
-> type_env * (ty * kind) env * string list 


fun typeDataDef ((T, kind, vcons), Gamma, Delta) = 
let (definition of validate, for the types of the value constructors of T $450a) 
val mu = freshTycon T 
val Delta' = bind (T, (TYCON mu, kind), Delta) 
fun translateVcon (K, tx) = (K, txTyScheme (tx, Delta')) 
val Ksigmas = map translateVcon vcons 


val () = app (fn (K, sigma) => validate (K, sigma, mu, kind)) 
Ksigmas 
val Gamma' = extendTypeEnv (Gamma, Ksigmas) 


val strings = kindString kind :: 
in (Gamma', Delta', strings) 
end 


map (typeSchemeString o snd) Ksigmas 


8.7.2 Translating type syntax into types 


Just as in Typed Scheme, type syntax written by a programmer isn’t trusted; non- 
sense like (int int) and (list -> list) is rejected by the type system. In Typed 
LScheme, it suffices to check the kind of each type, then pass the syntax on to the 
type checker. But in WML, the syntax of types is different from the internal repre- 
sentation used for type inference, so the syntax can’t be passed on. Instead, it is 
translated. 
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bind 305d 
type env 304 
extendTypeEnv 
S453c 
freshTycon S449b 
type kind 355a 
kindString S462d 


snd S249b 
txTyScheme S456c 
type ty 408 
TYCON 408 
type type_env 
435a 
typeSchemeString 
S431d 


validate $450a 
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The translation is expressed using two judgment forms, | Af t~+ 7 :: «| and 


Att~+o:: *| which translate ML type syntax into either a Hindley-Milner 
type or a type scheme, respectively. The rules are shown in Figure 8.6. The imple- 
mentation is so similar to Typed 4Scheme’s kind checking that I doubt you need to 
see it. But if you do, you will find functions txType and txTyScheme in Appendix S. 


8.7.3 Run-time representation of value constructors 


Datatype definitions are not only typed; they are also evaluated. Evaluating a 
datatype definition introduces a function or value for every value constructor. 
A value constructor with a function type gets a function; a value constructor 
with a non-function type is a value by itself. To tell which is which, function 
isPolymorphicFuntyex looks at the type syntax. As with nano-ML, evaluation isn't 
formalized. 


490. (typing and evaluation of data definitions 489) += (S437a) <489 


evalDataDef : data_def * value env -> value env * string list 


isPolymorphicFuntyex : tyex -> bool 


fun evalDataDef ((_, _, typed_vcons), rho) = 

let fun valFor (K, t) = if isPolymorphicFuntyex t then 

PRIMITIVE (fn vs => CONVAL (K, vs)) 
else 
CONVAL (K, []) 
fun addVcon ((K, t), rho) = bind (K, valFor (K, t), rho) 
in (foldl addVcon rho typed_vcons, map fst typed_vcons) 
end 


8.8 THEORY AND IMPLEMENTATION OF CASE EXPRESSIONS 


The operational semantics and type theory of pattern matching apply to any lan- 
guage with pattern-matching case expressions. 


8.8.1 Evaluation of case expressions and pattern matching 


As illustrated in Section 8.2.1, a case expression is evaluated by trying one choice af- 
ter another, selecting the first choice whose pattern matches the scrutinee. Ifan at- 
tempt at pattern matching succeeds, it produces an environment p’, which binds the 
variables that appear in the pattern. If the attempt at pattern matching fails, I say it 
produces { (pronounced “failure,” but think of a dagger in the heart). The { is not 
an environment or a value or an expression or anything we have encountered be- 
fore; it is a new symbol that means pattern-match failure. To stand for the result of 
a pattern match, which is either an environment p’ or , I use the metavariable r. 


The matching judgment therefore takes the form| (p,v) — r |: 


(p,v) — p’ Pattern p matches value v, producing bindings p’; 
(p,v) >} Pattern p does not match value v. 


Since patterns are matched only in the context of a case expression, understanding 
of pattern matching begins with case expressions. 

Acase expression is evaluated by first evaluating the scrutinee e, which involves 
no pattern matching. Once e is evaluated to produce a value v, the operational 
semantics puts v back into the scrutinee position as a literal expression. This trick 


Table 8.7: Correspondence between {sML’s type system and code 
(See also Table 7.3, page 432) 


Type system Concept Interpreter 
d Definition def (page 486) 
e€ Expression exp (page 486) 
t Type syntax tyex (page 486) 
we Variable name (page 303) 
K Value constructor vcon (page 486) 
p Pattern pat (page 486) 
T Syntactic type name 
a Type variable tyvar (page 408) 
LL Type constructor tycon (page 485) 
M Set of type constructors Hidden inside 
freshTycon (page S449) 
T Type ty (page 408) 
0, Va.T Type scheme type_scheme (page 408) 
T Type environment type_env (page 435) 
T, WT, Disjoint union disjointUnion (page 497) 
r+I"’ Extension <+> (page 305) 
C Constraint con (page 436) 
T1 ~T2 Equality constraint T1 ™ T2 (page 436) 
Ci AC, Conjunction C1 /\ C2 (page 436) 
T Trivial constraint TRIVIAL (page 436) 
iy C; Conjunction conjoinConstraints 
[Ci,..., Cn] (page 436) 
AkFterik Type elaboration txType (page S455) 
OX WIK Type compatibility validate (page S450) 
C,Tre:7 Type inference ty e = (7, C) (chunk 497a) 


C,Tl FE [pe]:t3>7' 


CLT,’ p:t 


(d,T,A,M) 31 


Type inference 
Type inference 


Type inference 


choicetype((p,e), [) = 
(rt > 7’, C) (page 497) 

pattype(p, [) = (I’,7,C) 

(page 498) 

typdef(d, [) = (I”, s) 

(page 439) and also 

typeDataDef (page 489) 


avoids the need for a special form of judgment that would otherwise try to match v 
with each choice in turn. The trick is implemented by this rule: 


(e,p,0) hu 


(CASE(LITERAL(v), [p1 €1],..- 


[Pn €n]),P,9) Pv 


(casE(e, [pi €1],--. 


» [Pn Cri) 9s o) fv’ 


(CASESCRUTINEE) 


Once the scrutinee is a literal v, pattern matching can begin. 
The value of the scrutinee is always matched against the first pattern p;. If that 
match succeeds, producing environment p’, the value of the case expression is the 
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bind 305d 
CONVAL 486d 
type env 304 
fst S249b 
isPolymorphic- 
Funtyex S452b 
PRIMITIVE 486d 
type tyex $454c 
type value 486d 
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Table 8.8: Correspondence between sML’s operational semantics and code 


Semantics Concept Interpreter 

e€ Expression exp (page 486) 
x Variable name (page 303) 
K Value constructor vcon (page 486) 
v) Pattern pat (page 486) 
v Value value (page 486) 

p+p' Extension <+> (page 305) 

pipe  Disjoint union disjointUnion (page 497) 


(p,v) > p’ Pattern matches match(p,v) = p’ (page 494) 
(p,v) — { Pattern match fails match(p,v) raises Doesn'tMatch 


value produced by evaluating the corresponding right-hand side e; in the extended 
environment p+ p’. 
(p1,v) > pe) (ern. pote) dv’ 
(CASE(LITERAL(v), [p1 €1],---, [Pn €n]),p,0) 4 v! 


(CASEMATCH) 


The extension p + p’ is defined for any two environments p and p’; environment p 
is extended by adding p”s bindings to it. 


dom(p + p’) = dom p U dom p’ 
(0+ Na) ={ 


p'(x), if € dom p’ 
p(x), if 2 ¢ dom p’ 


The + operation can also express an environment extended with bindings: 
p{t1 > U1,..-,2n 9 Unt = pt {a1 U1,...,2n > Un}. 


Back to the case expression: what if the first pattern doesn’t match? Evaluation 
continues with the next pattern. The operational semantics drops choice [p; €1] 
from the case expression, and it evaluates a new case expression whose first choice 


is [po €2]: 


(pi,v) > tT _ (CASE(LITERAL(v), [p2 €2],---, [Pn €n]),p,9) Vv’. 
(CASE(LITERAL(v), [pi €1],---, [Pn €n]), 9,0) Yu’ 


(CASEFAIL) 
What if there are no more choices—that is, what ifn = 1? Then no rule applies. 
The operational semantics gets stuck, and the interpreter raises the RuntimeError 
exception. 

Each rule is implemented as a clause for function ev. To avoid an infinite loop, 
the clauses for CASE(LITERAL(v), cs) must precede the clause for CASE(e, cs). 
The matching judgment is implemented by function match: if matching succeeds, 
it returns p’, and if not, it raises the exception Doesn'tMatch. In that case it’s time 
to try the remaining choices. 


492. (more alternatives for ev for nano-ML and uML 492)= (S429a) 493a> 
| ev (CASE (LITERAL v, match : pat * value -> value env 
(p, @€) :: choices)) = <+>  : 'a env * 'a env -> 'a env 


(let val rho' = match (p, v) 
in eval (e, rho <+> rho') 
end 

handle Doesn'tMatch => ev (CASE (LITERAL v, choices))) 


If no choices match a LITERAL form, then the case expression does not match. 


493a. (more alternatives for ev for nano-ML and uML 492) += 
| ev (CASE (LITERAL v, [])) = 
raise RuntimeError ("'case' does not match " A valueString v) 


(S429a) <492 493bp 


If the scrutinee e hasn't yet been evaluated, ev calls itself recursively to evaluate e, 
places the resulting value into a LITERAL expression, then tail-calls itself to select a 
choice. 
493b. (more alternatives for ev for nano-ML and ML 492) += 
| ev (CASE (e, choices)) = 
ev (CASE (LITERAL (ev e), choices) ) 


(S429a) <1493a 


Now that we know how matching is used, we can examine in detail, formally, 
how it works. We start with a simple but common special case: a value constructor 
applied to a list of variables. A pattern of the form (K 21 --- 2m) matches values 


of the form VCON(K, [v1,...,Um]). This case can be described by a specialized 
rule: 
Y1,..-,Lm all distinct 
p= {1 U4,...,Lm > Um} 


(SPECIALIZED MATCH RULE) 


(CK x1 +++ &m), VCON(K, [v1,... 


:Um])) > 


And the case is illustrated by this example: 


493c. (transcript 459a) += 
-> (case '(1 2 3 4 5) [(cons x xs) (cons x (reverse xs))]) 
(15 43 2) : (list int) 


<1488b 494aD> 


The simple case is easy: bind each variable to the corresponding value. But it’s 
too simple; in real code, patterns can be nested to arbitrary depth. Nesting com- 
plicates the theory, but, as you can see in some of the traffic-light examples in Sec- 
tion 8.1 and in Standard ML code throughout this book, nesting simplifies code. 
If you want to understand why programmers like algebraic data types, experiment 
with nested patterns. Once you're convinced they are worth having, you'll have an 
easier time with the theory. 

In general, when a value constructor K appears in a pattern p, K is applied not 
to a list of variables but to a list of sub-patterns: p = (K py, --- Pm). Each sub- 
pattern p; can introduce new variables, and bindings for all those variables have 
to be combined. When combining bindings, the operational semantics avoids the 
ambiguity that would arise if the same variable appeared in more than one binding: 
it combines bindings using a new operation, disjoint union. 

The disjoint union of environments p, and p2 is written 9; p2, and it is defined 
if and only if dom p; MN dom pz = 0: 


dom(p; & p2) = dom p; U dom po, 


(01 8 a)(e) = { 


pi(x), if € dom p, 
p2(x), if e € dom po. 


What if pattern-matching fails, so there is no environment? Disjoint union can be 
extended to all pattern matching results; disjoint union of failure with any result is 
still failure: 


TW =F. 


This extended definition is implemented by function disjointUnion in Appendix S. 
Using it, aconstructor application is matched by combining the results of matching 


TYp=t pet=t 
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<+> 305f 
CASE 486b 
cons B 
Doesn'tMatch 

494b 
type env 304 
ev S429a 
eval S429a 
LITERAL S438a 
match 494b 
type pat 486c 
reverse B 
rho S429a 
RuntimeError 

$213b 


type value 486d 
valueString S461b 


its argument patterns: 


(Di, Vi) > Ta; 1l<i<m 
r=71W:---Wrn . 
(Kk Plc: Pm), VCON(K, Keer -;Um])) amelie 


(MATCHVCON) 


Because disjoint union is associative and commutative, results r; can be combined 
in any order. Andif any sub-pattern fails to match, the whole pattern fails to match. 


User-defined, a Iso fail een 1 : de with K 
algebraic types (and constructor pattern also fails to match when value v 1s not made wit. . 
pattern matching) v does not have the form vcon(K, [v1,..., Um]) (FAILVcon) 

7 (CK py ++ Pm), 0) > T 


Other patterns match using much simpler rules. A bare value constructor 
matches only itself, and it produces no bindings. 


(MATCHBAREVCON) 
(A, vcon(K, [])) — {} 
VcoNn (Ic. 
toe VEON(ES LI) (FAILBAREVCON) 
(K,v) > 
A wildcard matches any value, and it produces no bindings. 
(MATCHWILDCARD) 


(WILDCARD, v) — {} 


A variable matches any value v, and it produces a binding of itself to v. 


MATCHVAR 
(0) > (or v} 
The result of matching any pattern to any value is determined by the six rules 

above. Let’s look at an example and a derivation, this time with a nested pattern: 

494a. (transcript 459a) += <1493c 499> 
-> (case '(1 2 3 4 5) [(cons x1 (cons x2 xs)) (cons x2 (cons x1 xs))]) 
(213 45) : (list int) 

The derivation tree, which applies rule MATCHVAR at each leaf and MATCHVCON 

at each internal node, looks like this: 


(x2, 2) + {x2 2} (xs, '(345)) > {xs '(345)} 
(x1, 1) > {x1 1} ((cons x2 xs), vcon(cons, [2,'(345)])) + {x2+> 2,xsH> '(345)} 
(cons x1 (cons x2 x8)), vcoN(cons, [1, vcoN(cons, [2, '(3 45)])])) > {x1 +> 1, x24 2,xs-4 '(345)}- 


The rules are implemented by function match, which implements judgment 
(p,v) — p’ by returning p’. And it implements judgment (p,v) — T{ by raising 
the ML exception Doesn'tMatch. 
494b. (definitions of match and Doesn'tMatch 494b)= (S438e) 


match : pat * value -> value env (* or raises Doesn'tMatch *) 


disjointUnion : 'a env list -> 'a env 


exception Doesn'tMatch (* pattern-match failure *) 
fun match (CONPAT (k, ps), CONVAL (k', vs)) = 
if k = k' then 
disjointUnion (ListPair.mapEq match (ps, vs)) 
else 
raise Doesn'tMatch 
| match (CONPAT _, _) = raise Doesn'tMatch 
| match (WILDCARD, _) = emptyEnv 
| match (PVAR x, v) = bind (x, v, emptyEnv) 


If patterns ps and values vs were lists of different lengths, function ListPair.mapEq 
would raise an exception, but “ML’s type system ensures that this can’t happen. 


8.8.2 Type inference for case expressions and pattern matching 


Like any other type system, jsML’s type system guarantees that run-time compu- 
tations do not “go wrong.” jsML’s type system extends nano-ML’s type system to 
provide these guarantees: 


* When a value is constructed using CONVAL, the value constructor in question 
is applied to an appropriate number of values of appropriate types. 


+ Inevery pattern, every value constructor is applied to an appropriate number 
of sub-patterns of appropriate types. 


* In every case expression, every pattern in every choice has a type consistent 
with the type of the scrutinee. And every variable in every pattern is bound 
to a value that is consistent with the type and value of the scrutinee. 


* In every case expression, the right-hand sides all have the same type, which 
is the type of the case expression. 


As in any type system, these guarantees are provided by a combination of type- 
formation rules, introduction rules, and elimination rules. WML uses all of the rules 
used in nano-ML, plus rules for constructed data. 


- As in other languages that support algebraic data types, type formation is 
governed by a kinding system like the one used in Typed zScheme; both 
implicit-data and data definition forms specify the kind of each new type. 


* The introduction form for constructed data is the named value constructor. 
Its typing rule is just like the typing rule for a named variable: look up the 
typeinT. 


* The elimination form is the case expression, which includes patterns. The 
typing rules for case expressions and patterns are the subject of this section. 


Like nano-ML, /sML has two sets of typing rules: nondeterministic rules and 
constraint-based rules. 


Nondeterministic typing rules for case expressions, choices, and patterns 


LML inherits all the judgment forms and rules from nano-ML. Its basic nonde- 


terministic judgment form is still] [[ e: 7 |. But case expressions and pattern 
matching call for new judgment forms. The easiest form to explain is the one 
that deals with a choice within a case expression; the form of the judgment is 


IT} [p e]: 7-7’ |. In this form, type 7 is the type of pattern p and type 7’ is 


the type of expression e. Informally, the judgment says that if a case expression is 
scrutinizing an expression of type 7, and if pattern p matches the value of that ex- 
pression, then in the context of that match, expression ¢€ has type rT’. The judgment 
is used in the nondeterministic typing rule for a case expression: 


Tke:f 
DE ipl sree Les. . 
TF case(e, [pi €1],---, [Pn €n]):7' 


(CASE) 


Every pattern p; has the same type as the scrutinee e, and every right-hand side e; 
has type 7’, which is the type of the whole case expression. 

As in the dynamic semantics, the key judgment is a pattern-matching judg- 
ment. And also as in the dynamic semantics, pattern matching produces an 
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environment—a type environment, not a value environment. But compared with 
the dynamic semantics, the type system is more complicated: 


* Type inference produces not only an output environment I”, which gives the 
types of the variables that appear in the pattern, but also a type 7, which is 
the type of the whole pattern. 


* As inputs, the dynamic semantics requires only the pattern and the value to 
be matched. In particular, the dynamic semantics requires no environment. 
But type inference requires an input environment, which tells the system the 
type of every value constructor that appears in the pattern. 


The typing judgment for pattern matching therefore requires inputs p and T and 
produces outputs 7 and I’. This two-input, two-output judgment form is written 


[,I’ + p: 7}. The notation is inspired by the notation for typechecking an ex- 


pression (Exercise 33). 
When p is a bare value constructor, it has the type it is given in the input envi- 
ronment, and it produces an empty output environment. 


TKK: 


Nee wes ee (PATBAREVCON) 


The premise is a typing judgment for the expression K’, which is a value construc- 
tor. Just like a value variable, a value constructor is looked up and instantiated: 


I(kK)=0o tT <o 
TE K:7' 


(VCON) 


A wildcard pattern has any type and produces the empty output environment. 


(PATWILDCARD) 


T, {} + witpcarp : + 


A variable pattern also has any type, and it produces an output environment that 
binds itself to its type. 


Tj{anr}ha:r Ce 
The most important pattern is one that applies a value constructor K to a list of 
sub-patterns: p = (K pi --: Pm). The types of the sub-patterns must be the 
argument types of the value constructor, and the type of the whole pattern is the 
result type of the value constructor. Each sub-pattern p; can introduce new vari- 
ables; the environment produced by the whole pattern is the disjoint union of the 
environments produced by the sub-patterns (page 493). If the disjoint union isn’t 
defined, the pattern doesn’t typecheck. 


TEK:% X+++X OT 
DMF pem, l<icm 
Y= u---wol, 


PATV 
D,IYF CK py +++ pm) 2 T PAEVCON} 


The judgment for patterns is used in the rule for a choice [p e]. Typing pat- 
tern p produces a set of variable bindings I’, and the right-hand side e is checked 
in a context formed by extending [ with I’, which holds p’s bindings: 


TI,’ p:r T+I”Fe:7’ 
TF [pe]:t77’ 


(CHOICE) 


The CHOICE rule concludes the nondeterministic type theory of case expressions. 


Constraint-based type inference for case expressions, choices, and patterns 


To turn the nondeterministic rules into an inference algorithm, I introduce con- 
straints. Just as in Chapter 7, each occurrence of an unknown type is repre- 
sented by a fresh type variable, and within each rule, multiple occurrences are 
constrained to be equal. The rules are shown in Figure 8.9 on the following page. 
They are implemented using the same ty representation used in nano-ML. 

The CASE rule checks the scrutinee and each choice. 


Ce, re: 
Ci,0 [pp e]:%, l<i<n 
C’ = \,{t ~ (7 > a@)}, where ais fresh 
CH=COATAC A+++ ACy 
C,T  cask(e, [pi e1],---, [Pn €n]): a 


(CASE) 


The scrutinee judgment C., I’ | e : 7 is implemented by function typeof (Chap- 
ter 7), and the choice judgment C;,I + [p; e;] : 7; is implemented by function 
choicetype (bottom of this page). Each constraint in the set {7; ~ (rT > a)} is 
built by applying internal function constrainArrow to 7;. 


497a. (more alternatives for ty 497a)= (438c) 
ty : exp -> ty * con 

: * = * 
| ty (CASE (e, choices)) = Eyeeon : exp type_env -> ty con 
choicetype : (pat * exp) * type_env -> ty * con 


let val (tau, c_e) = 


typeof (e, Gamma) 
val (tau_i's, c_i's) = 
ListPair.unzip (map (fn ch => choicetype (ch,Gamma)) choices) 
val alpha = freshtyvar () 
fun constrainArrow tau_i = tau_i ~ funtype ([tau], alpha) 
val c' = conjoinConstraints (map constrainArrow tau_i's) 
val c = c_e /\ c' /\ conjoinConstraints c_i's 
in (alpha, c) 
end 


Function ListPair.unzip converts a list of pairs to a pair of lists. 
The rule for a choice infers a type for the pattern and the expression: 


CT,’ Fp: C’,T+I"’Fe:7' 
CAC',TE[pe]:t>7' 


(CHOICE) 


Function choicetype returns a pair containing the arrow type 7 —> 7’ and the 
conjoined constraint C' A C’. 


497b. (definition of function choicetype 497b)= (S453a) 


choicetype : (pat * exp) * type_env -> ty * con 


fun choicetype ((p, e), Gamma) = 
let val (Gamma', tau, c) = pattype (p, Gamma) 
val (tau', c') = typeof (e, extendTypeEnv (Gamma, Gamma')) 
val (ty, con) = (funtype ([tau], tau'), c /\ c') 


val _ = (check p, e, Gamma', Gamma, ty, and con for escaping skolem types S460f) 


in (ty, con) 
end 


The combination I + I” is implemented by function extendTypeEnv, which is de- 


fined in the Supplement. (Because Iisa type_env, notaty env, itcan’t be extended 


using the <+> function.) 
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T(K) =Vay,...,Qn-T 


ai,..., a, are fresh and distinct 


TE K: ((a, a})0-+-0 (a, 4 al,)) Tr 


C,T- [p e]:1t37' CHOICE 


CLT,’ + p:t 


PATBAREVCON 
TTFKK: 7 


CLT,’ tb p:r CO’7.[+I”’te:7' 
CAC T[pel:tro7 


PATVCON 
TCE K : t, 

CT, ppt, L<i<m 
C=TK~T1 X +++ X Tm — Q, where ais fresh 
C’=CiA---ACm Y= Tw--- wl, 

CAC T,I’' CK py +++ pm) i a 


PATWILDCARD PATVAR 
a is fresh a is fresh 


Tb K:r 


T,T,{} + witpcarp : a TTj{tvna}sFa:a 


Figure 8.9: Constraint-based rules for case expressions, choices, and patterns 


Function pattype has four cases: one for each rule. 


498. (definition of function pattype 498)= ($453a) 
pattype : pat * type_env -> type_scheme env * ty * con 
fun pattype (p as CONPAT (vcon, pats as _ :: _), Gamma) = 
let val vcon_tau = pvconType (vcon, Gamma) 

val (Gamma'_is, tau_is, c_is) = pattypes (pats, Gamma) 

val alpha = freshtyvar () 

val c = vcon_tau ~ funtype (tau_is, alpha) 

val c' = conjoinConstraints c_is 

val Gamma' = disjointUnion Gamma'_is 


in 
end 


handle DisjointUnionFailed x => 
raise TypeError ("name " A x A" is bound multiple " A 
"times in pattern " A patString p) 


(Gamma', alpha, c /\ c') 


| pattype (CONPAT (K, []), Gamma) = 
CemptyEnv, pvconType (K, Gamma), TRIVIAL) 
| pattype (WILDCARD, _) = 
CemptyEnv, freshtyvar(), TRIVIAL) 


| pattype (PVAR x, 


as 


let val alpha = freshtyvar () 
(bind (x, FORALL ([], alpha), emptyEnv), alpha, TRIVIAL) 


in 
end 


and pattypes (ps, Gamma) = unzip3 (map (fn p => pattype (p, Gamma)) ps) 


The type of a value constructor vcon () comes from pvconType (chunk S452d), 
which instantiates vcon’s type scheme with fresh type variables. 


The implementations of pattype and pattypes complete type inference for 
case expressions. Inference code for the other expressions, except for value con- 
structors, is shared with nano-ML. Type inference for a value constructor instanti- 
ates its type scheme with fresh variables; the code appears in the Supplement. 


8.9 ALGEBRAIC DATA TYPES AS THEY REALLY ARE 


Algebraic data types and pattern matching are found primarily in the ML family of 
languages and in languages descended from them, including Standard ML, OCaml, 
Haskell, Clean, Coq/Gallina, Agda, Idris, and more. All support algebraic data types 
as presented in this chapter, but some offer extended or restricted versions. 


8.9.1 Syntax 


Syntax varies. The implicit-data form is used in Standard ML, OCaml, standard 
Haskell, and Clean; the data form is used in Agda and Coq/Gallina. Both forms are 
used in Idris and by the Glasgow Haskell Compiler. Spelling of value constructors 
also varies; in Standard ML, value constructors are typically written in all capital 
letters; elsewhere, they are typically written with a single, initial capital letter. 

Examples of concrete syntax, including datatype definitions, case expressions, 
and clausal definitions, can be found in any of the interpreters in this book from 
Chapter 5 onward. As is typical, pattern matching and decision making are done 
primarily by means of clausal definitions, not by case expressions. Because clausal 
definitions look so much like algebraic laws, they are preferred. 

Pattern matching is used in Erlang, even though Erlang does not have algebraic 
data types (or even a type system). Erlang’s pattern matching is defined over terms; 
the role of value constructors is played by atoms. Erlang includes both case expres- 
sions and clausal function definitions. 

Pattern matching is so popular that it is sometimes used in other contexts. For 
example, in the multiparadigm language Scala, algebraic data types are encoded 
using objects and classes, but the language also includes a case expression written 
using the keyword match. As a more whimsical example, Nigel Horspool has used 
Java exception handlers to implement pattern matching. 


8.9.2 Additional checking: Exhaustiveness and redundancy 


An algebraic data type is closed: once it is defined, new value constructors can’t be 
added. Because each type is closed, a compiler can analyze each case expression 
and see if at run time, every possible value is guaranteed to be matched by some 
pattern. The analysis is called the exhaustiveness check. An exhaustiveness check 
is mandated by the Definition of Standard ML (Milner et al. 1997), but the Definition 
also requires that inexhaustive matches be let off with a mere warning. No such 
latitude is extended to my students. 

When acase expression’s patterns are not exhaustive, evaluating the expression 
can cause a run-time error. Here’s an example: 


499. (transcript 459a) += <1494a 
-> (define last (xs) last : (forall ['a] ((list 'a) -> 'a)) 
(case xs 
[(cons y '()) y] 
[(cons _ ys) (last ys)])) 
-> (last '(1 2 3)) 
3: int 
-> (last '()) 
Run-time error: 'case' does not match () 
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When checking for exhaustiveness, a compiler may discover a pattern that can 
never match. Such a pattern is often called redundant. (It’s redundant because it 
can be removed without changing the behavior of the program.) Most compilers 
warn of redundant patterns; confusingly, the Glasgow Haskell Compiler refers to 
such patterns as “overlapped” or “overlapping.” 

“Overlapping” is also used to describe a pair of patterns that match one or more 
values in common. When patterns overlap, the first matching pattern is always 
chosen. Overlapping patterns are useful; for example, if just one case needs spe- 
cial handling, you can put a very specific pattern like (cons _ (cons _ zs)) before 
a general pattern like the wildcard, even though the specific pattern and the wild- 
card overlap. Non-overlapping patterns are also useful; if no patterns overlap, then 
patterns in a case expression or clauses in a definition can be written in any or- 
der, without changing the meaning of the program. But non-overlapping patterns 
are primarily a conceptual tool: they simplify equational reasoning. If you cared 
whether patterns overlapped, your compiler could easily tell you, but no compiler 
I know of actually does. 


8.9.3 Efficient implementation 


In modern compilers, constructed values are represented efficiently. A value con- 
structor that takes no arguments is typically represented by a small integer that 
fits in a machine register. A value constructor that has been applied to arguments 
is typically represented by a pointer to an object allocated on the heap; the object 
holds the arguments as well as a small-integer tag that identifies the value con- 
structor. In some important special cases, such as list and option, where only 
one value constructor takes any arguments, the tag can be omitted. 

Pattern matching is also compiled efficiently. Each case expression is trans- 
lated by a match compiler, which produces a finite-state automaton. In the automa- 
ton, each initial or intermediate state examines the small-integer tag associated 
with one value constructor, then makes a transition to another state. Each final 
state knows which pattern matches, where all the bound variables are located, and 
how to transfer control to the corresponding right-hand side. At run time, an ini- 
tial or intermediate state is typically implemented by a load instruction and an in- 
direct branch; a final state is implemented by a direct branch. Pattern-matching 
automata come in two flavors: a backtracking automaton has compact code, but it 
may examine some tags more than once; a decision tree examines each tag at most 
once, but in pathological cases it may require space exponential in the size of the 
source code. 

In strict languages like Standard ML and OCaml, pattern matching causes no 
side effects, and the match compiler may examine the arguments of any value con- 
structor in whatever order it thinks best. Finding the best order is an NP-complete 
problem, so most compilers resort to heuristics; if you want to know more, consult 
the Further Reading section. In a lazy language like Haskell or Clean, however, 
pattern matching can have a side effect: it can trigger the evaluation of an expres- 
sion that would otherwise go unevaluated. To make such evaluations predictable, 
the order in which arguments must be examined is dictated by the language defi- 
nition, and the match compiler must obey. 

In general, pattern matching is cheap, and in an important special case, it has 
no run-time cost at all: when an algebraic data type has only one value constructor, 
and when that value constructor takes exactly one argument, applying or matching 
on that value constructor should cost nothing. There’s an example in Section H.2.4: 


datatype 'a collection = C of ‘a set 


At run time, a collection has the same representation as a set, which happens to 
be the same representation as a list. But to the type system, they are different— 
I use a collection in circumstances where I have both collections and lists and 
I want to avoid confusing the two (Exercise 38). 


8.10 SUMMARY 


Case expressions and pattern matching not only simplify conditional logic but 
also reduce the amount of boilerplate needed to get at parts of product values 
(records). And clausal definitions, which use pattern matching, make it possible 
for the definition of a function to look an awful lot like the function’s algebraic 
laws. The succinctness and readability of pattern matching is highly valued by 
many programmers—sometimes even more than type inference. 


8.10.1 Key words and phrases 


ALGEBRAIC DATA TYPE A data type whose values may be one ofa set of enumerated 
alternatives, in which each alternative is a CONSTRUCTED VALUE created by 
a unique VALUE CONSTRUCTOR. Each of a type’s value constructors may be 
applied to other values of given types, making the entire algebraic data type 
a SUM OF PRODUCTS. 


CASE EXPRESSION The core-language elimination form for an ALGEBRAIC DATA 
TYPE. It examines a CONSTRUCTED VALUE, called the SCRUTINEE, and it pro- 
vides a sequence of choices, each of which has a PATTERN on the left and an 
expression on the right. When the case expression is evaluated, the result is 
determined by the first choice whose pattern matches the scrutinee. 


CLAUSAL DEFINITION A definition form for functions. A clausal definition is writ- 
ten as a sequence of clauses, each of which applies the function to a PATTERN 
and equates that application to an expression on the right-hand side. When 
the function is applied, it executes the first clause whose pattern matches. 
A clausal definition desugars to an ordinary definition whose body is a CASE 
EXPRESSION. 


CONSTRUCTED VALUE A value created by applying a VALUE CONSTRUCTOR to one 
or more values. Or a value constructor that does not expect any arguments. 


GENERATIVITY A definition form is generative when the thing it defines is distinct 
from all other things, even when the other things’ definitions look identical. 
The definition of an ALGEBRAIC DATA TYPE is typically generative, which im- 
plies that the type and its value constructors are distinct from types and value 
constructors introduced by other definitions—even if the other definitions 
use the same type name and the same constructor names. 


PATTERN A syntactic form that is unique to CASE EXPRESSIONS. A pattern is a lit- 
eral, a variable, or a VALUE CONSTRUCTOR applied to patterns. A pattern 
matches any CONSTRUCTED VALUE that can be obtained by replacing each 
variable in the pattern with some actual value. 


PATTERN MATCHING The algorithm by which a choice is selected in a CASE EX- 
PRESSION. In industrial compilers an interpreters, pattern matching is im- 
plemented by an efficient automaton that is compiled from the patterns in 
the case expression. 
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SCRUTINEE A value of algebraic data type that is examined in a CASE EXPRESSION. 


SUM OF PRODUCTS Describes a set of structured values that is a discriminated 
union (sum), in which each element of the sum may carry a record-like col- 
lection (product) of other values. In general, an ALGEBRAIC DATA TYPE is a 
sum of products. In object-oriented language, a set of subclasses of a given 
class can also form a sum of products. 


TYPE ABBREVIATION A definition form that enables a programmer to add a new 
name to the environment, where the new name refers to a type that is already 
present in the program. In some languages, a type abbreviation may take 
parameters, just like a type constructor. Compare with USER-DEFINED TYPE. 


USER-DEFINED TYPE A definition form that enables a programmer to add a new, 
named type to the environment. Typically the new type is distinct from any 
existing type, making the type-definition form GENERATIVE. Compare with 
TYPE ABBREVIATION. 


VALUE CONSTRUCTOR The name of an alternative in an ALGEBRAIC DATA TYPE. 
A value constructor is either a CONSTRUCTED VALUE by itself or may be ap- 
plied to arguments to make a constructed value. Value constructors are also 
used to form PATTERNS for use in case expressions. Except in very old pro- 
gramming languages, a value constructor can usually be distinguished from 
a variable by looking at its lexical form. For example, value constructors may 
be capitalized and variables may not. 


8.10.2 Further reading 


Algebraic data types were first explored in the experimental language HOPE, de- 
scribed by Burstall, MacQueen, and Sannella (1980). Among other concerns, 
Burstall and his colleagues wanted to support user-defined types, to help program- 
mers avoid forgetting cases, and to avoid cluttering the environment with names 
for functions like nu11?, car, and cdr, which they replaced with pattern matching. 

Algebraic data types don’t have to be closed: Millstein, Bleckner, and Cham- 
bers (2004) present a design that makes them extensible. Sadly, the design has not 
caught on. 

The type theory and operational semantics in this chapter draw heavily on the 
Definition of Standard ML (Milner et al. 1997). The Definition is worth reading, but 
it presents two challenges: First, it describes a whole language, the complexity of 
which can't be avoided. Second, its notation can be hard to follow: the rules rely not 
only on subtle differences between forms of judgment but also on implicit premises 
that are mentioned only briefly at the beginning of some sections. But the truth is 
all there, and while I could not call the Definition elegant, I admire its parsimony. 
Anyone reading the Definition is advised also to have the Commentary (Milner and 
Tofte 1991), which contains not only discussion but also many worked examples of 
problems similar to those in this book. 

If you want to tackle the Definition of Standard ML, I owe you two additional cau- 
tions. First, I find the terminology challenging. For example, I believe that the Def- 
inition uses the words “type name” and “type constructor” the way I use the words 
“type constructor” and “type name.” (I stand by my guns.) Second, the treatment 
of generativity in the Definition is now widely believed to be inferior—it is too much 
a description of an implementation, it has too much mechanism, and it may be too 
difficult to reason about. A surprising alternative is to treat generative data defi- 
nitions as a special case of generative modules (Harper and Stone 2000). The idea 


Table 8.10: Synopsis of all the exercises, with most relevant sections 


Exercises Sections Notes 


1 8.1,8.2 Check your understanding of pattern matching. 

2 to 4 8.1,8.2 Pattern matching on lists and pairs. 

5 to7 8.1,8.2 Higher-order functions on lists. 

8 and9 8.2 Using option. 

10 to 12 8.2 Using order: Comparisons and sorts. 

13 to 19 8.2 Tree structures: join lists, binary trees, tries, and ternary 
search trees. 

20and21 8.3 Equational reasoning. 

22 to 28 8.4 Using and implementing syntactic sugar. 

29and30 8.5 Type generativity. 

3land32 8.7 Kinds; type abbreviations; type constraints. 

33 to 38 8.8 Properties of pattern matching; extensions; finding 


non-exhaustive patterns. 


is further developed in a very nice if very technical paper by Dreyer, Crary, and 
Harper (2003). 

Algebraic data types lend themselves to some nice extensions. In Appendix S, 
you can read about existentially quantified value constructors and generalized al- 
gebraic data types (GADTs). Existential quantification is suggested by Mitchell and 
Plotkin (1988) as a way of coding abstract types; its use with value constructors was 
first suggested by Perry (1991). GADTs are beautifully introduced by Hinze (2003), 
and some nice applications are presented by Pottier and Régis-Gianas (2006) and 
by Ramsey, Dias, and Peyton Jones (2010). 

The compilation of ML pattern matching into decision trees was first described 
by Baudinet and MacQueen (1985), who claim NP-completeness and present a num- 
ber of heuristics. Scott and Ramsey (2000) present preliminary experiments sug- 
gesting that in practice, choice of heuristics may not matter; they also present 
pseudocode for a match compiler. But the definitive work in this area is by 
Maranget (2008), who carefully compares decision trees with backtracking au- 
tomata. Maranget also develops new heuristics and also a fine methodology for 
experimental evaluation. In a separate paper, Maranget (2007) describes checks 
for exhaustiveness and redundancy. 


8.11 EXERCISES 


The exercises are summarized in Table 8.10. The highlights include some nice data 
structures: 


* The “zipper” (Exercise 16) is a purely functional data structure whose oper- 
ations have an imperative feel. It’s a classic. If you're a beginner, the zipper 
is a good challenge problem. If you have more experience and you have not 
yet seen the zipper, you will find it very satisfying. 


* Binary tries (Exercises 17 and 18) connect tries with binary representations 
of integers in a way that has a nice theory and a nice implementation. And 
ternary search trees (Exercise 19) show how case expressions and pattern 
matching make it easy to code tree algorithms. 


The remaining highlights explore the theory and implementation of WML. 
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* The concrete syntax of patterns resembles the concrete syntax of a subset 
of expressions (those formed from value variables, value constructors, and 
function application). You can confirm this resemblance by showing that a 
pattern and its corresponding expression have the same type (Exercise 33). 


* Pattern matches should be checked to make sure they are exhaustive and no 
patterns are redundant. You can implement this check and simultaneously 
get a feel for how pattern matches can be compiled into efficient code (Exer- 
cise 38). 


8.11.1 Retrieval practice and other short questions 


Ao oO WD 


What are some examples of value constructors? 

What are some examples of algebraic data types? 

Is constructed data always made with a value constructor? If not, when is it not? 
Is a value constructor always constructed data? If not, when is it not? 


What’s the idiomatic way to compare two values when both are constructed 
data, like the color of a traffic light? 


What is the option type and how is it used? What are its value constructors? 
What are the possible forms of a pattern? 

When does matching a pattern add new bindings to the environment? 

How can you tell the difference between a value constructor and a variable? 


If K is a value constructor defined with algebraic type 7’, what do the typing 
rules tell us about the type of K? 


In WML, how often should you expect to use predefined functions nu11?, car, 
and cdr? 


In AML, what is the result type of the predefined function find? Why does the 
LML version return something different from the Scheme version? 


What other expression form is (case € [x e’] --- ) equivalent to? 
What is a clausal definition and why would you want one? 


What’s the most important difference between a generative type definition and 
a type abbreviation? 


What is the judgment form A} t ~» 7 :: * and what problems does it solve? 


What are the meanings of the two judgments (p,v) — p’ and (p,v) —> fT? 
What's an example of each? 


The typing rules for case expressions include a specialized judgment that takes 
the form I+ [p e] : 7 > 7’. In this form, what are the types 7 and 7’? 


If the patterns in a case expression are exhaustive, what does that tell us about 
the evaluation of the case expression? 


8.11.2 Understanding pattern matching 


1. Identify matching values. Test your understanding of pattern matching by see- 
ing which values are matched by the pattern (PAIR (cons x (cons y zs)) w). 
For each of the following expressions, tell whether the pattern matches the 
value denoted. If the pattern matches, say what value is bound to each of the 
four variables x, y, zs, and w. If it does not match, explain why not. 
505a. (sample expressions 505a) = 

(PAIR '(1 2 3) (PAIR 'Fisher 105)) 
(PAIR (PAIR 'Fisher 105) '(1 2 3)) 
(PAIR '(#t #f) 314159) 

(PAIR '(a) '(b c d)) 

(PAIR '(a b) '(c d)) 

(PAIR '(a bc) '(d)) 


8.11.3 Pattern matching: Lists and pairs 


If you can, write the functions in this section using define*. You can implement it 
yourself (Exercise 26), or if you are using this book for a class, your instructor may 
have my implementation. 


2. Match a list of pairs of integers. Define a function consecutive-pair that takes 
a list of integers and returns, as a pair, the first two consecutive integers in 
the given list that are also consecutive in the list of all integers. If there is no 
such pair, consecutive-pair should return NONE. Use only two patterns: the 
wildcard pattern and the nested pattern (cons n (cons mms)). 
505b. (exercise transcripts 505b) = 505¢ > 

-> consecutive-pair 

<function> : ((list int) -> (option (pair int int))) 
-> (consecutive-pair '(6 1 7)) 

NONE : (option (pair int int)) 

-> (consecutive-pair '(7 8 1)) 

(SOME (PAIR 7 8)) : (option (pair int int)) 

-> (consecutive-pair '(4 3 3 4)) 

(SOME (PAIR 3 4)) : (option (pair int int)) 


3. Create a list of pairs. Define a function zip that takes a pair of lists (of equal 
length) and returns the list of pairs containing the same elements in the same 
order. If the lengths don’t match, pass the symbol 'length-mismatch to the 
error primitive. Do not use if, null1?, car, or cdr. 
505c. (exercise transcripts 505b) += <1505b 506aD 

-> zip 

<function> : (forall ['a 'b] ((list 'a) (list 'b) -> (list (pair 'a 'b)))) 
-> (zip '(a bc) '(1 2 3)) 

((PAIR a 1) (PAIR b 2) (PAIR c 3)) : (list (pair sym int)) 

-> (zip '(a bc) '()) 

Run-time error: length-mismatch 


4. Nested patterns. If your zip from Exercise 3 includes more than one case ex- 
pression, reimplement it using a single case expression, while still adhering 
to all the restrictions in Exercise 3. 
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8.11.4 Higher-order functions on lists and option 


5. Using option values. Define a function List. find which generalizes function 


exists? by producing a witness (if one exists). Given a predicate p? anda 
list xs, List. find returns (SOME v) if xs contains a value v satisfying p?, and 
NONE otherwise. 
506a. (exercise transcripts 505b) += <1505¢ 506b> 

-> List.find 

<function> : (forall ['a] (('a -> bool) (list 'a) -> (option 'a))) 

-> (define positive? (n) (> n 0)) 

-> (List.find positive? '(-3 -2 -1 0 1 2 3)) 

(SOME 1) : (option int) 

-> (List.find (lambda (n) (> n 100)) '(-3 -2 -1 0 1 2 3)) 

NONE : (option int) 


. Consuming option values. A partial function from 7 to 7’ can be repre- 


sented by a total function of type 7 — 1’ option. Such a function can be 
mapped over a list, keeping only the SOME results. In this example I map the 
consecutive-pair function from Exercise 2. 


506b. (exercise transcripts 505b) += 1506a 506c> 
-> map-partial 
<function> : (forall ['a 'b] (('a -> (option 'b)) (list 'a) -> (list 'b))) 
-> (map consecutive-pair (list6 '(1 2 3) "(4 5 6) 
'"(1976) '(2 01 4) 
"(7 7 42) '(4 3 3 4))) 
(C(SOME (PAIR 1 2)) (SOME (PAIR 4 5)) NONE (SOME (PAIR © 1)) ... 
-> (map-partial consecutive-pair (list6 '(1 2 3) "(4 5 6) 
'"(1976) '(2 01 4) 
"(7 7 42) '(4 3 3 4))) 
((PAIR 1 2) (PAIR 4 5) (PAIR © 1) (PAIR 3 4)) : (list (pair int int)) 


Without using if, nu11?, car, or cdr, implement map-partial. 


. Removing option values. Define function keep-somes, which takes a list of 


option values and returns only the SOME values, with SOME stripped off. 
506c. (exercise transcripts 505b) += <1506b 506d> 
-> keep-somes 
<function> : (forall ['a] ((list (option 'a)) -> (list 'a))) 
-> (keep-somes 
(list6 NONE (SOME 'freedom) NONE NONE (SOME 'is) (SOME 'slavery))) 
(freedom is slavery) : (list sym) 


8.11.5 Functions on option alone 


8. Maps over option. Define function Option.map, which acts like map but works 


on option values, not list values. 


506d. (exercise transcripts 505b) += <1506c 507a> 
-> Option.map 
<function> : (forall ['a 'b] (('a -> 'b) (option 'a) -> (option 'b))) 
-> (Option.map positive? NONE) 
NONE : (option bool) 
-> (Option.map positive? (SOME 4)) 
(SOME #t) : (option bool) 
-> (Option.map reverse NONE) 
NONE : (forall ['a] (option (list 'a))) 
-> (Option.map reverse (SOME '(1 2 3))) 
(SOME (3 2 1)) : (option (list int)) 


9. 


Nested option. Define function Option.join, which takes an “option of 
option” and returns a single option that is SOME whenever possible: 


507a. (exercise transcripts 505b) += <1506d 507b> 
-> Option.join 
<function> : (forall ['a] ((option (option 'a)) -> (option 'a))) 
-> (Option.join (SOME NONE)) 
NONE : (forall ['a] (option 'a)) 
-> (Option.join (SOME (SOME 4))) 
(SOME 4) : (option int) 


8.11.6 Functions that use order 


10. 


11. 


12. 


Comparison using order. Define a higher-order sort function mk-sort of type 

(forall ['a] (('a 'a -> order) -> ((list 'a) -> (list 'a)))). Avoid 

using if, nul1?, car, and cdr. 

507b. (exercise transcripts 505b) += <1507a 507¢> 
-> mk-sort 


<function> : (forall ['a] (('a 'a -> order) -> ((list 'a) -> (list 'a)))) 


-> (mk-sort Int.compare) 

<function> : ((list int) -> (list int)) 

-> (it '(0 215 5)) 

(0 125 5) : (list int) 

-> (val sort-down (mk-sort (lambda (n m) (Int.compare m n)))) 
-> (sort-down '(0 2 15 5)) 

(55210) : (list int) 


Merge sort via pattern matching. Without using if, nul11?, car, or cdr, define a 
higher-order mergesort function, which should have the same type as above: 
(forall ['a] (('a 'a -> order) -> ((list 'a) -> (list 'a)))). I recom- 
mend defining a top-level mergesort that takes compare as an argument, and 
which contains a letrec that defines split, merge, and sort. 


Unlike most sorting algorithms, mergesort requires two base cases: not 
only is a list matching '() considered sorted, but so is a list matching 
(cons x '()). Your sort function should therefore discriminate among 
three cases—the two base cases and one inductive case. The inductive case 
splits the list into two smaller lists, sorts each, and merges the results. 


Higher-order functions with order. Comparison is useful not just on individual 
values but on pairs, triples, lists, and so on. Such comparisons are typically 
lexicographic: you compare the first elements, and if they are unequal, that’s 
the result of the comparison. But if the first elements are equal, you compare 
the remaining elements lexicographically. Try your hand at the higher-order 
functions below. Use case expressions, and look for opportunities to use the 
wildcard pattern. 


(a) Without using if, define function compare-like-pairs, which is given 
a comparison function for values of type 7 and returns a comparison 
function for values of type T Xx T. 
507c. (exercise transcripts 505b) += <1507b 508a> 

-> (check-type compare-like-pairs 
(forall ['a] (('a 'a -> order) -> 
((pair 'a 'a) (pair 'a 'a) -> order)))) 


(Test cases appear on the next page.) 
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Your implementation of compare-like-pairs should pass these tests: 
508a. (exercise transcripts 505b) += <1507¢ 508b > 
-> (val compare-NxN (compare-like-pairs Int.compare) ) 
-> (check-expect (compare-NxN (pair 1 2) (pair 3 4)) LESS) 
-> (check-expect (compare-NxN (pair 7 2) (pair 3 4)) GREATER) 
-> (check-expect (compare-NxN (pair 3 2) (pair 3 4)) LESS) 
-> (check-expect (compare-NxN (pair 3 4) (pair 3 4)) EQUAL) 
-> (check-expect (compare-NxN (pair 3 5) (pair 3 4)) GREATER) 


(b) Define function compare-pairs, which is given two comparison func- 
tions, one for values of type 7 and one for values of type r’, and returns 
a comparison function for values of type 7 x 7’. 
508b. (exercise transcripts 505b) += <1508a 508¢> 
-> (check-type compare-pairs 
(forall ['a 'b] (('a 'a -> order) ('b 'b -> order) -> 
((pair 'a 'b) (pair 'a 'b) -> order)))) 


(c) Use compare-pairs to implement compare-like-pairs. 


(d) Define function compare-lists, which is given a comparison function 
for values of type 7 and returns a comparison function for values of type 
T list. Lists should be ordered lexicographically (dictionary order), 
and the empty list should be considered smaller than any nonempty 
list. The function should pass these tests: 
508c. (exercise transcripts 505b) += <1508b 514aD 
-> (val compare-Ns (compare-lists Int.compare)) 


-> (check-expect (compare-Ns '(2 1 3 4) '(2 1 4 8)) LESS) 

-> (check-expect (compare-Ns '(2 15 5) '(2 1 4 8)) GREATER) 
-> (check-expect (compare-Ns '(2 15 5) '(2 15 5)) EQUAL) 

-> (check-expect (compare-Ns '(2 15 5) '(e 1)) GREATER) 
-> (check-expect (compare-Ns '(2 15 5) '(2 1 4 8 1)) GREATER) 
-> (check-expect (compare-Ns '(2 1 4 8) '(2 1 4 8 1)) LESS) 


(e) Use compare-pairs to implement compare-lists without matching a 
value of type order directly. 


8.11.7 Tree structures 


An algebraic data type defines a set of trees, and pattern matching is exceptionally 
good for writing recursive functions on trees. 


13. 


14. 


Binary trees. Implement a function bt-depth that gives the depth of a binary 
tree from Section 8.1 (page 463). An empty tree has depth zero; a nonempty 
tree has depth 1 more than the maximum depth of its subtrees. 


Binary search trees. A binary search tree can represent a finite map, which is to 
say a set of key-value pairs in which each key appears at most once. A binary 
search tree is one of the following: 


* The empty tree, which represents the empty set of key-value pairs 


« An internal node, which has a key, a value, a left subtree, and a right 
subtree, and which represents the singleton set containing the given 
key and value, unioned with the sets represented by the left and right 
subtrees 


Every binary search tree satisfies an order invariant. The empty tree satis- 
fies the order invariant by definition. An internal node satisfies the order 
invariant if it has all of these properties: 


* The left subtree satisfies the order invariant. 
+ The right subtree satisfies the order invariant. 
+ Every key in the left subtree is smaller than the key in the internal node. 


+ Every key in the right subtree is greater than the key in the internal 
node. 


Using an algebraic data type, implement a binary search tree. Use pattern 
matching, not if. Ideally your tree will be polymorphic in both keys and 
values, but if it simplifies things sufficiently, you could use integer keys. 


(a) Define an algebraic data type that represents binary search trees. I rec- 
ommend that your algebraic data type include a value constructor that 
takes no arguments and that represents an empty tree. 


(b) Define an insert function that takes a key, a value, and a tree, and re- 
turns a new tree that is like the original tree, but binding the given key 
to the given value. (In particular, if the given key is present in the old 
tree, the new tree should associate that key with the new value.) 


(c) Define a lookup function that takes a key and a tree. If the tree as- 
sociates the key with a value v, the function should return (SOME v). 
If not, the function should return NONE. 


(d) Define a delete function that takes a tree and a key, and returns a tree 
that is equivalent to the original, except that the key is not associated 
with any value. If you are not familiar with deletion in binary search 
trees, the usual heuristic is to reduce every case to the problem of delet- 
ing the key-value pair from a given internal node. This problem divides 
into three overlapping cases: 


If the left subtree is empty, the internal node can be replaced by 
the right subtree. 

If the right subtree is empty, the internal node can be replaced by 
the left subtree. 

* If neither subtree is empty, delete the largest key-value pair from 
the left subtree. Form a new internal node using that key-value 
pair along with the modified left subtree and the original right sub- 
tree. 


(e) Define a record type that holds insert, lookup, and delete functions. 
Define a polymorphic function that takes a compare function and re- 
turns such a record. 


(f) Define a function treefoldr that does an inorder traversal of a binary 
search tree. For example, given tree t, 


(treefoldr (lambda (key value answer) (cons key answer)) '() t) 
will return a sorted list of the keys in the tree. 
15. Sequences with fast append. List append takes time and space proportional 


to the length of the left-hand argument. In this problem, you define a new 
representation of sequences that supports append in constant time. 
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Informally, a sequence of 7’s is either empty, or it is a single value of type 7, 
or it is a sequence of 7’s followed by another sequence of 7’s. 


(a) 


(b) 


(c) 


(d) 


(e) 


(f) 


(g) 


Use this informal definition to define an algebraic datatype seq of kind 

(* => *). As with any abstraction that is defined by choices, your defi- 

nition should contain one value constructor for each choice. 

Define s-cons, with type (forall ['a] ('a (seq 'a) -> (seq 'a))), to 

add a single element to the front of a sequence, using constant time and 

space. 

Define s-snoc, with type (forall ['a] ('a (seq 'a) -> (seq 'a))), to 

add a single element to the back of a sequence, using constant time and 

space. (As always, snoc is cons spelled backward.) 

Here the order of arguments is the opposite of the order in which the 

results go in the data structure. That is, in (s-snoc x xs), x follows xs. 

The arguments are the way they are so that s-snoc can be used with 

foldl and foldr. 

Define s-append, type (forall ['a] ((seq'a) (seq 'a) -> (seq 'a))), 
to append two sequences, using constant time and space. 

Define list-of-seq, with type (forall ['a] ((seq 'a) -> (list 'a))), 
to convert a sequence into a list containing the same elements in the 

same order. Function list-of-seq should allocate only as much space 

as is needed to hold the result. 


Without using explicit recursion, define function seq-of-list, with 
type (forall ['a] ((list 'a) -> (seq 'a))), which converts an ordi- 
nary list toa sequence containing the same elements in the same order. 


Ideally, function list-of-seq would take time proportional to the 
number of elements in the sequence. But when a sequence contains 
many empty-sequence constructors, it can take longer. Prevent this 
outcome by altering your solutions to maintain the invariant that the 
empty-sequence value constructor never follows or is followed by an- 
other sequence. 


16. Emulating mutable lists. When lists are immutable, as they are in uScheme 
and in the ML family, they appear not to support typical imperative opera- 
tions, like inserting or deleting a node at a point. But these operations can be 
implemented on purely functional data structures, efficiently, in ways that 
look imperative. The implementation uses a technique called the zipper. 


You will learn the zipper by implementing a list with indicator. A list with 
indicator is a nonempty sequence of values, together with an “indicator” that 
points at one value in the sequence. Elements can be inserted or deleted at 
the indicator, in constant time. 


(a) 


(b) 


Define a representation for type ilist of kind (* => *). Document your 
representation by saying, in a short comment, what sequence is meant 
by any value of type 'a ilist. 
Given a good representation, the code is easy: almost every function 
can be implemented as a case expression with one or two choices, each 
of which has a simple right-hand side. But a good representation might 
be challenging to design. 
Support the documentation in part (a) by writing list-of-ilist: 
510. (list-with-indicator functions 510)= 5llap 
(check-type list-of-ilist 
(forall ['a] ((ilist 'a) -> (list 'a)))) 


(c) 


(d) 


(e) 


(f) 


(g) 


Define function singleton-ilist, which takes a single value and re- 
turns a list whose indicator points at that value. 


511a. (list-with-indicator functions 510) += 1510 511b> 
(check-type singleton-ilist (forall ['a] ('a -> (ilist 'a)))) 


Define function at-indicator, which returns the value the indicator 
points at. 


511b. (list-with-indicator functions 510) += <51la 511c> 
(check-type at-indicator (forall ['a] ((ilist 'a) -> 'a))) 


To move the indicator, define indicator-left and indicator-right, 
with these types: 
511c. (list-with-indicator functions 510) += <511b 511d> 
(check-type indicator-left 
(forall ['a] ((ilist 'a) -> (option (ilist 'a))))) 
(check-type indicator-right 
(forall ['a] ((ilist 'a) -> (option (ilist 'a))))) 


Calling (indicator-left xs) creates a new list ys that is like xs, ex- 
cept the indicator is moved one position to the left. And it returns 
(SOME ys). But if the indicator belonging to xs already points to the 
leftmost position, then (indicator-left xs) returns NONE. Function 
indicator-right is similar. Both functions must run in constant time 
and space. 

These functions “move the indicator,” but no mutation is involved. In- 
stead of mutating an existing list, each function creates a new list. 


To remove an element, define delete-left and delete-right, with 
these types: 
511d. (list-with-indicator functions 510) += <51lc 51le> 
(check-type delete-left 
(forall ['a] ((ilist 'a) -> (option (ilist 'a))))) 
(check-type delete-right 
(forall ['a] ((ilist 'a) -> (option (ilist 'a))))) 


Calling (delete-left xs) creates a new list ys that is like xs, except 
the element to the left of the indicator has been removed. And it re- 
turns (SOME ys). If the indicator points to the leftmost position, then 
delete-left returns NONE. Function delete-right is similar. Both 
functions must run in constant time and space, and as before, no mu- 
tation is involved. 


To insert an element, define insert-left and insert-right, with 
these types: 
51l1e. (list-with-indicator functions 510) += 511d 512ap 
(check-type insert-left 
(forall ['a] ('a (ilist 'a) -> (ilist 'a)))) 
(check-type insert-right 
(forall ['a] ('a (ilist 'a) -> (ilist 'a)))) 


Calling (insert-left x xs) returns a new list that is like xs, except the 
value x is inserted to the left of the indicator. Function insert-right is 
similar. Both functions must run in constant time and space. As before, 
no mutation is involved. 
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17. 


(h) Define functions ffold1 and ffoldr, with these types: 
512a. (list-with-indicator functions 510) += <51le 
(check-type ffoldl 
(forall ['a 'b] (('a 'b -> 'b) 'b (ilist 'a) -> 'b))) 
(check-type ffoldr 
(forall ['a 'b] (('a 'b -> 'b) 'b (ilist 'a) -> 'b))) 


These functions do the same thing as foldl and foldr, but on lists with 
indicators. They ignore the position of the indicator. 


To test these functions, start with the list test-ilist defined below. The list 
is created by a sequence of insertions, plus a movement. To emphasize the 
imperative feel of the abstraction, test-ilist is created by using let* to 
rebind the name xs repeatedly. The code should remind you of a sequence 
of assignment statements. 
512b. (list-with-indicator test cases 512b)= 512¢> 
(val test-ilist 
(let* ((xs (singleton-ilist 3)) 

(xs (insert-left 1 xs)) 

(xs (insert-left 2 xs)) 

(xs (insert-right 4 xs)) 

(xs (case (indicator-right xs) ((SOME ys) ys))) 

(xs (insert-right 5 xs))) 

XS)) 


The resulting test-ilist should be the list '(1 2345), with the indicator 
pointing at 4. It should pass these tests: 
512c. (list-with-indicator test cases 512b) += <1512b 
(check-expect (list-of-ilist test-ilist) '(1 2 3 4 5)) 
(check-expect (at-indicator test-ilist) 4) 
(check-expect (Option.map list-of-ilist (delete-left test-ilist)) 
(SOME '(1 2 4 5))) 


Tries as sets. A binary trie searches by looking at bits of aninteger. A binary trie 
can represent a set of integers, and set union, intersection, and difference 
are easy to implement efficiently. You'll implement a little-endian binary trie, 
which looks at the least-significant bits first. 


A binary trie has three kinds of nodes: empty, singleton, and union. 


* The empty trie represents the empty set of integers. 


* The singleton trie contains a single integer n, and it represents the sin- 
gleton set {n}. 


The union trie contains two subtries e and o (for “even” and “odd”), 
which represent sets |e] and [o], respectively. In the little-endian form, 
the union trie represents the set 


{2-k| ke [ef}U{2-k41| ke fof}, 


where 2 - k means twice k. As a consequence of this definition, when 
you are looking for an element n in a union trie, you look in e if n is 
even and in o if n is odd—and either way, in the sub-trie you look for 
n div 2. 


Implement a little-endian binary trie as follows: 
(a) Define an algebraic data type ints that represents a binary trie, which 
in turn represents a set of integers. 


(b) Define function ints-member?, which tells whether an integer is in the 
set. 


(c) Define function ints-insert, which inserts an integer into the set. 


(d) Define function ints-delete, which removes an integer from the set, $8.11 
if present. Exercises 
(e) Define function ints-union, which takes the union of two sets. Find 513 


an implementation that allocates fewer CONVALs than simply union by 
repeated insertion. 


(f) Define function ints-inter, which takes the intersection of two sets. 
(g) Define function ints-diff, which takes the intersection of two sets. 


(h) Define function ints-fold, which folds over all the integers in a trie. 
Give it type (forall ['a] ((int 'a->'a) 'aints->'a)). 


As a representation of sets, the binary trie has some redundancy: 


* The empty set can be represented not only as an empty trie, but also 
as the union of two empty tries—or the union of any two tries that each 
represent the empty set. The empty set is represented most efficiently 
as the empty trie. 


+ Asingleton set can be represented not only as a singleton trie, but also 
as the union of a singleton trie and an empty trie—or the union of any 
two tries that respectively represent the appropriate singleton set and 
the empty set. A singleton set is represented most efficiently as a sin- 
gleton trie. 


The potential redundancy can be eliminated by wrapping the value construc- 
tor for union in a “smart constructor”: 


(i) Revisit the functions you have implemented above, and identify which 
functions can create a union node of which one child is empty and the 
other is either empty or singleton. 


(j) Rewrite the functions you have implemented above so that no function 
ever creates a union node of which one child is empty and the other 
is either empty or singleton. The standard technique is not to use the 
value constructor for union directly, but to define a smart constructor: 
Asmart constructor is a function that, at the abstract level, has the same 
specification as a value constructor, but at the representation level, can 
may be more efficient. For the binary trie, the smart constructor should 
recognize two special cases: union of empty and empty should return 
empty, and union of singleton n and empty should return either single- 
ton 2-7 or singleton 2 - m + 1. In other cases, the smart constructor 
should behave like the value constructor for a union trie. 


18. Tries as finite maps. Generalize your results from Exercise 17 to implement a 
finite map with integer keys. 


(a) To represent a finite map with integer keys, define an algebraic data 
type intmap of kind (* => *). 


(b) Define values and functions with these types: 
514a. (exercise transcripts 505b) += <1508c 514b> 
-> (check-type empty-intmap 
(forall ['a] (intmap 'a))) 
-> (check-type intmap-insert 
(forall ['a] (int 'a (intmap 'a) -> (intmap 'a)))) 
-> (check-type intmap-find 


User-defined, (forall ['a] (int (intmap 'a) -> (option 'a)))) 
algebraic types (and -> (check-type intmap-delete 
pattern matching) (forall ['a] (int (intmap 'a) -> (intmap 'a)))) 
-> (check-type intmap-fold 
514 (forall ['a 'b] 


((int 'a 'b -> 'b) 'b (intmap 'a) -> 'b))) 


19. Search trees with lists as keys. A ternary search tree combines aspects of a trie 
and of a binary search tree. The original ternary search tree is specialized to 
null-terminated C strings (Bentley and Sedgewick 1997, 1998). The ternary 
search tree that you will implement is polymorphic: it works with any type 
of list. 


A tree of type (ternary 7, 7) represents a finite map whose keys have type 
(list 7.) and whose values have type 7. A ternary search tree has two 
species of nodes: a decision node and a final node. 


* A decision node contains a decision element d of type 'a, and it has three 
children, each of which is also a ternary search tree: 


- The left subtree stores all key-value pairs whose keys are lists that 
begin with an element that is smaller than d. 

- The right subtree stores all key-value pairs whose keys are lists that 
begin with an element that is larger than d. 

- The middle subtree stores all the key-value pairs whose keys have 
the form (cons d xs). However, in the middle subtree, only the zs 
part of the key is used—the d part is implicit in the position of the 
middle subtree directly under a decision node. 


In addition to its three subtrees, the decision node also stores the value 
whose key is the empty list (if any). 


« A final node stores only the value whose key is the empty list, if any. 
It has no children. 


This exercise has three parts: 


(a) Using an algebraic data type, define a representation of ternary search 
trees. 


(b) Define function ternary-insert, to insert a key-value pair into a ter- 
nary search tree. 


(c) Define function ternary-find, to look up a key in a ternary search tree. 


Your functions should be higher-order and should have these types: 


514b. (exercise transcripts 505b) += 1514a 522bp 
-> (check-type ternary-find 
(forall ['a 'b] (('a 'a -> order) -> 
((list 'a) (ternary 'a 'b) -> (option 'b))))) 
-> (check-type ternary-insert 
(forall ['a 'b] 
(C'a 'a -> order) -> 
((list 'a) 'b (ternary 'a 'b) -> (ternary ‘a 'b))))) 


Hint: The case that’s easy to get wrong is the one in which the key is an empty 
list. Ifyou can associate a value with the empty list and look it up successfully, 
you're on your way. 


8.11.8 Equational reasoning 


20. Laws of tree traversal. Using equational reasoning, prove two laws about func- 
tion preorder-elems, which is defined on page 463. 


(preorder-elems BTEMPTY) = '() 
(preorder-elems (BTNODE x ti t2)) = (cons x (append (preorder-elems t1) 
(preorder-elems t2))) 


21. Laws of case expressions. In all functional languages, one of the most impor- 
tant compiler optimizations is function inlining. Inlining sometimes results 
in expressions that have a “case-of-case” structure: 


(case 
(case e€ [pi €1] ++: [Dr ek]) 
[pe] 


[Perey 


Write an algebraic law that will enable a compiler to rewrite such an expres- 
sion so that the scrutinee is not a case expression. Assume that all the ex- 
pressions are evaluated without side effects, so duplicating code is OK. (With 
luck, any duplicate code will be eliminated by applications of laws described 
in Section 8.3.) 


8.11.9 Syntactic sugar 


In the exercises below, you implement the “patterns everywhere” syntactic sugar 
described in Section 8.4. This sugar makes 44ML almost as expressive as core ML. 
(“Almost” because 4ML does not support exceptions.) By and large, the exercises 
don’t touch code related to evaluation or type checking; all they do is extend the 
LML parser (Appendix S, page S462). The parsers in the appendix contain some 
“hooks” and extra code that should make things easier—you can focus on the desug- 
aring functions. 


22. Benefits of clausal definitions. Using define* as described in Section 8.4 
(page 481), rewrite the implementation of preorder-elems to make the laws 
in Exercise 20 blindingly obvious. 


23. Patterns for lambda parameters. Using syntactic sugar, extend jsML’s lambda 
expression so that each formal parameter is a pattern, not just a variable 
(Section 8.4, page 480). 


* In the exptable function of Appendix S, change the lambda case to use 
parser patFormals instead of formals; patFormals parses a list of pat- 
terns in brackets. 


* Redefine function lambda to rewrite a list of patterns as a list of vari- 
ables, adding a case expression. If the list of patterns is empty, the 
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24. 


25. 


26. 


27. 


LAMBDA takes no arguments, and it need not be transformed. Other- 
wise, where lambda takes one or more patterns as arguments, imple- 
ment the desugaring with the help of functions freshVars to get new 
names for the arguments, tupleexp to form a scrutinee, and tuplepat 
to build the single pattern that goes in the case expression. 


Even with this extension, many lambda expressions use only PVAR patterns. 
These lambda expressions can be transformed using case, but if you instead 
convert them to ordinary lambda expressions without case, your code will 
be easier to debug. 


Patterns for define parameters. Using syntactic sugar, extend .ML’s define 
form so the formal-parameter list is a list of patterns, not just a list of vari- 
ables (Section 8.4, page 480). Replace the formals parser with patFormals, 
and rewrite the define function. Asin Exercise 23, use freshVars, tupleexp, 
and tuplepat—if you’ve done Exercise 23, you may be able to reuse code. 
And as in Exercise 23, if all the patterns are PVAR patterns, it’s better not to 
introduce a case expression. 


Clausal lambda expressions. Using syntactic sugar, implement the lambda* 
expression (Section 8.4, page 482). Don’t change any parsers; just update 
the ML code in Appendix S to replace the lambdastar function with one 
that returns OK e, where e is a lambda expression. As above, use freshVars, 
tupleexp, and tuplepat to good advantage. And your lambdastar function 
should check that each list of patterns has the same length (shown as n on 
page 482). The check isn’t strictly necessary, but if it is omitted and the 
lengths aren’t equal, the error messages are baffling. 


Clausal definitions. Using syntactic sugar, implement clausal definitions. 
That is, implement the define* form (Section 8.4, page 481). Don’t change 
any parsers; just update the ML code in Appendix S to replace the definestar 
function with one that returns OK d, where dis a definition. If you have done 
Exercise 25, use ML function lambdastar to implement definestar. 


Pattern binding in let expressions. Using syntactic sugar, implement the 
transformation that enables let expressions to bind patterns, not just vari- 
ables (Section 8.4, page 482). Rewrite the letx expression-builder func- 
tion in Appendix S, which should now take a (pat * exp) list instead of a 
(name * exp) list. Your new letx function must handle three cases: 


* Ifthe parser is configured correctly, a LETREC uses only PVAR patterns, 
and it can be converted to an ordinary LETREC. If your LETREC case en- 
counters a pattern that is not a PVAR, your interpreter should halt with 
a fatal error message. 


+ A LETSTAR should be desugared into nested LETs in the standard way. 


+ ALET should be desugared as shown on page 482. The desugaring must 
be applied to each pattern/expression pair. 


You will also need to replace these parsers in the exptable function: 


Original zML —_sML with patterns everywhere 


letBs patBs 
letstarBs patBs 
letrecBs patLetrecBs 


28. Pattern binding in val definitions. Using syntactic sugar, extend val so it can 


bind to a pattern (Section 8.4, page 483). Add a new row to UML’s xdeftable, 
with the usage string "(val pat e)" and parser valpat <$> pattern <*> exp. 
The valpat function is a new definition builder that you need to write. 
It should build one val binding for each free variable of the given pattern; 
free variables can be found using function freePatVars. Once built, the 
bindings are combined with a binding to it, and the list of bindings is 
wrapped in the secret DEFS constructor. 


Perform the full desugaring only if the pattern in the val is in CONPAT form. 
If the pattern is a variable or a wildcard, turn it into a variable and move on. 


8.11.10 Type generativity 


29. Generativity in C. InC, a struct definition is generative. A struct definition is 


30. 


any occurrence of struct that is followed by a list of fields in curly braces. 
For example, the definition 


517a. (generativity.c 517a)= 517b> 
typedef struct point *Point; 


does not include a struct definition, because no fields are given. But the 
declaration 


517b. (generativity.c 517a) += <517a 
double distance_from_origin(struct point {double x; double y; 3); 


does include a struct definition, because fields are given—even though those 
fields are in unusual places. 


This exercise will help you discover how generativity works in C and how 
your favorite C compiler deals with it. 


(a) Write a C program that contains at least two distinct struct definitions, 
both of struct point, and both containing two doub1e fields x and y. 


(b) Extend your C program so that you try to use one struct point where 
the other one is expected, causing a compile-time error. 


(c) Find a C compiler that complains about your program of part (b), say- 
ing that it expected struct point but found struct point instead—or 
something similar. 


Generativity in Modula-3. In most statically typed languages, generativity is 
associated with a particular syntactic form: in the ML family, the definition 
of an algebraic data type; in C, the definition of a struct or union. Such 
languages give programmers no choices: if you define a particular species of 
type, the definition is generative. 


Modula-3, by contrast, lets you choose which types are generative (Cardelli 
et al. 1992). No type is generative by default, but any pointer type can be made 
generative by branding it, using the BRANDED keyword. (Pointer types are 
called “references,” and the corresponding type constructor is written REF.) 


(a) Consult the language definition for Modula-3—try not to distract your- 
self with subtyping—and design a similar branded mechanism for jsML. 
Update the formal system to account for brands, and give additional 
rules for the translation of type syntax into types. 


(b) Write rules for type equivalence that account for brands. 
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(c) Write introduction and elimination rules for expressions that have 
branded types. This part of the exercise may suggest to you why the 
designers of Modula-3 limited branding to reference types. 
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32. 


Kinds. Show that jsML’s kind system is a conservative extension of Typed 
pScheme’s kind system. Start with a definition of erasure: 


* The erasure of the empty environment is the empty environment. 


- If A is the erasure of environment A, then the erasure of environment 


A’ = A{T & (1,4)} is A{T 6 ke}. 


* The erasure of judgment AF t~+ 7 :: Kisjudgment AF 7 :: k. 
Prove both of the following claims: 


(a) If there is a derivation of At t ~» 7 :: «, then there is a derivation of 
AF Tik. 

(b) Ifthere isa derivation of Aj F 7 :: K, then there exist a t anda A such 
that Ap = A and there is a derivation of AF t~ 7 :: kK. 


Type abbreviations. As your programs get more sophisticated and types get 
bigger, you will wish for type abbreviations. In this exercise, you get them. 
You will change the rules and the code for the type translation on page S455. 


(a) Change environment A so that a type name T may stand for one of two 
things: 
+ Atype 
- A function from a list of types to a type 


(b) To keep things simple, change the KINDAPP rule so that only a type 
name T’can be applied. The rule will then work as long as T stands for 
a type. 


(c) When T stands for the function \q1,..., @p.T, use this new rule: 


A(t) = (Aqy,..., Qn-T, #1 X ++ X Kp => K) 
AFL Ve Hu Ki, 1<i<n ; 
AF (t ty +++ th) TlarO 71,.--,AQn OO Tr] kK 
(KINDAPPABBREV) 


(d) Implement the new semantics in function txType. 


(e) Add a new definition form (type [tax ee On I] T t), which enters T 
into A as the appropriate function on types. 


8.11.12 Theory and implementation of pattern matching 


33. 


Types of patterns and expressions. A pattern is a variable, a wildcard, or a con- 
structor application. Except for the wildcard, each of these syntactic ele- 
ments can also be used to form an expression. Put patterns into one-to-one 
correspondence with a subset of expressions and show that this correspon- 
dence preserves types: 


34. 


35. 


(a) For each form of pattern p except the wildcard, show the corresponding 
expression form |p]. For clarity, you may wish to express the corre- 
spondence as an ML function of type (pat -> exp). 

(b) Use metatheory to prove that if p has no wildcard, andifl',I’ + p: 7, 
then +I’ [p] : 7. 

(c) Extend the expression syntax with a new form HOLE, written in the con- 
crete syntax as _. A hole behaves like a name with type scheme Va.a. 

a ¢ ftv(T) 


HOLE HOLE, WITH CONSTRAINTS 
[+ HOLE: 7 T,T/ HOLE: a@ 


(d) Given the extension in part (c), use metatheory to prove that regardless 
of whether p has a wildcard, iff, I’ + p:7,thenD +I’ +t [p]: 7. 


Pattern-match failures. Using the operational semantics, prove that if there 
is a derivation of the judgment (p,v) — {, then the derivation contains an 
instance of either the FAILVCON rule or the FAILBAREVCON rule. 


Type inference for patterns. The constraint-based rules for typechecking pat- 
terns (Figure 8.9, page 498) do more bookkeeping than they have to. The con- 
straint can be eliminated: instead of judgment C,T',I’ + p : 7, new rules 
can use the simpler judgment ’,I’’ + p : 7. Constraint C' is eliminated by 
finding a substitution 6 that solves C' and whose domain is the free variables 
of C.. The original derivation is transformed by applying @ to it. The resulting 
judgment about p is 9C,T', 01” | p : 07, and since OC = T by definition, 
this transformation leads to the simpler judgment form. 

The hard part of the exercise is to show that applying 6 doesn’t affect the type 
that is inferred in the rest of the derivation. 


(a) Prove that in any derivation of the judgment T,I’ | K : 7, the free 
variables of 7 are distinct from the free variables of I’. 

(b) Byinduction over derivations of judgments of the form C,T', I’ + p: 7, 
prove that the free type variables of C are distinct from the free type 
variables of I’. 


(c) Byinduction over derivations of judgments of the form C,T', I’ + p: 7, 
prove that the free type variables of I” are distinct from the free type 
variables of I’. 


(d) Prove that in a valid derivation of C,I F e : 7, if there is a subderiva- 
tion of C’,T',I’ + p: 7’, and if 6 is a substitution whose domain is 
contained in fv(C’), and if @C’ = T, then 


i. Substitution 6 can affect only the types of the new bindings I” and 
the type 7’ of pattern p. 
ii. Applying 6 to the entire derivation results in a valid derivation. 
iii. Applying 0 does not change 7, that is, 9r = T. 


The preceding results imply that constraint C' can be eliminated by solving 
it eagerly at each application of the PATVCON rule. 


(e) Write new rules for the judgment form IT’, I’ + p: 7. Except for choice 
of fresh type variables, your rules should be deterministic. Rules PAT- 
BAREVCON, PATWILDCARD, and PATVAR can be rewritten simply by re- 
moving the trivial output constraint. The PATVCON rule needs to solve 
constraint C' and apply the resulting substitution to I’ and a. (Con- 
straints C),..., C;, are all trivial, and therefore so is constraint C’.) 


$8.11 
Exercises 


519 


User-defined, 
algebraic types (and 
pattern matching) 


520 


36. 


37. 


38. 


(f) Simplify the CHOICE rule. 
(g) Rewrite the code to reflect your new, simpler rules. 


Matching integer literals. Extend pattern matching so it is possible to match 
on an integer literal. An integer-literal pattern has type int, introduces no 
bindings, and matches only the corresponding integer value. 


(a) Extend the parser, type checker, and evaluator of WML to support 
integer-literal patterns. 


(b) Using patterns, write a recursive Fibonacci function that does not 
use if. 


Matching quoted symbols. Extend pattern matching so it is possible to match 
a quoted symbol. A quoted-symbol pattern has type sym, introduces no bind- 
ings, and matches only the corresponding symbol. Extend the parser, type 
checker, and evaluator of “ML to support quoted-symbol patterns. 


Exhaustive or redundant patterns. Section 8.9.2 on page 499 describes checks 
for exhaustive and redundant patterns. Given a scrutinee of type T, a set of 
patterns is exhaustive if every value that inhabits type 7 is matched by some 
pattern. In this exercise you write an analysis that prints a warning message 
when it finds a non-exhaustive or redundant pattern match. 


The idea is this: Suppose you have the set of all possible values of type T. 
And suppose that, for each member of this set, you can tell if it does or does 
not match a particular pattern p. Then you can check for both exhaustiveness 
and redundancy using an iterative algorithm that maintains a set of all values 
not yet matched. 


* The set is initially the set of all values of type T. 


+ At each step of the iteration, the set is split into two subsets: those that 
do and do not match pattern p. 


* The set that matches p must not be empty; otherwise pattern p is re- 
dundant. 


* The set that does not match p is passed on to the next pattern. 


« At the end of the iteration, if the set of values not yet matched is non- 
empty, the pattern match is not exhaustive. 


There’s only one snag: for interesting types, the sets are infinite. To represent 
such sets, I define a “simple value set” to be one of two choices: 


+ All values of type 7, for a given T 


- A given value constructor K’, applied to a list of zero or more simple 
value sets 


A full set of values is a collection of simple sets, using the collections defined 
in Section H.2.4 (page $218). 


520. (exhaustiveness analysis for sML 520)= (S420b) 521b> 
datatype simple_vset = ALL of ty 
| ONE of vcon * simple_vset list 
type vset = simple_vset collection 


In the analysis, each set of values is classified according to whether it does 
or does not match a pattern. Full sets can be classified, simple sets can be 
classified, and even lists of sets can be classified. Start with this code: 


521a. (exhaustiveness analysis for .ML [prototype] 521a)= 522a> 
classifyVset : pat -> vset -> (bool * simple_vset) collection 
classifySimple : pat -> simple_vset -> (bool * simple_vset) collection 


fun classifyVset p vs = joinC (mapC (classifySimple p) vs) 
and classifySimple p vs = raise LeftAsExercise "match classification" 


Classification takes a single value set as input and produces a collection as 
output. A simple value set vs is classified by a pattern p as follows: 


* If pis a wildcard or a variable, it always matches, and the result is a 
singleton collection containing (true, vs). 


* Ifpis (K py --- py) and vs is the application of a different construc- 
tor kK’, then vs doesn’t match, and the result is a singleton collection 
containing (false, vs). 


* Ifpis (K py --- pn) and vsis (K vy, --- Un), then the value-set list 
V1 +++ Unis classified against the pattern list p; --- p,. Dothis usinga 
third function, classifyList. The empty value-set list always matches 
the empty pattern list, andthe subset of vy; --- v, matching p; --- Dy 
is the subset of v,; matching p; combined with the subset of v2--- vu, 
matching p2---pn. To implement classifyList, use recursion, use 
classifySimp1le, and use the collection function map2C. 


Finally, ifpis (KK p, --- py) and vs is ALL T, change ALL 7 to unroll T 
and try again. When 7 is an algebraic data type, unroll 7 returns a vset 
that is equivalent to ALL 7 but that does not use ALL at top level. 


521b. (exhaustiveness analysis for sML 520) += 
fun unroll tau = 
let val mu = case tau of TYCON mu => mu 
| CONAPP (TYCON mu, _) => mu 
| _ => raise BugInTypeInference "not ADT" 
fun ofVcon (name, sigma) = 
let val tau' = freshInstance sigma 
val argTys = case asFuntype tau' 
of SOME (args, res) => 
let val theta = solve (res » tau) 
in map (tysubst theta) args 
end 
| NONE => [] 
in ONE (name, map ALL argTys) : simple_vset 
end 
in C (map ofVcon (vconsOf mu)) 


(S420b) 4520 
: ty -> vset 


unroll 


end 


Function call vconsOf mu returns the name and type scheme of each 
value constructor associated with mu. Function vconsOf is omitted from 
this book. 


Using this classification, the exhaustiveness check can be implemented in 
three stages, as described on the next page. 
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Implement the exhaustiveness check in three stages: 


(a) 


(b) 


(c) 


522b. 


Implement classifySimple, but leave out the case of matching value 
constructors. 


Implement classifyList, which has type 
pat list * simple_vset list -> (bool * simple_vset list) collection, 


and use it to complete the implementation of classifySimp1le. Classify 
lists using these rules: 
* The empty list of values always matches the empty list of patterns. 
+ Alist of values v :: vs matches a list of patterns p :: ps ifand only 
if v matches p and also vs matches ps. 
Implement exhaustivenessCheck, replacing this placeholder: 


522a. (exhaustiveness analysis for 4ML [prototype] 521a) += <52la 


exhaustivenessCheck : pat list * ty -> unit 


fun exhaustivenessCheck (ps, tau) = 
eprintin "(Case expression not checked for exhaustiveness.)" 


The replacement should compute successive value sets that are as yet 
unmatched. Start with the value-set collection singleC (ALL tau), and 
classify value sets using each pattern from ps in turn. Issue a warning 
message for each redundant pattern, and if the list of patterns is not 
exhaustive, issue a warning for that too. 


You can test your code on these examples: 


(exercise transcripts 505b) += <1514b 


-> (lambda (z) (case z [(SOME _) #t] [_ #f] [NONE #f] [_ #f])) 
Warning: in choice 3, pattern NONE cannot match 

Warning: in choice 4, pattern _ cannot match 

<function> : (forall ['a] ((option 'a) -> bool)) 

-> (lambda (z) (case z [(SOME _) #t] [NONE #f] [_ #f])) 
Warning: in choice 3, pattern _ cannot match 

<function> : (forall ['a] ((option 'a) -> bool)) 

-> (lambda (z) (case z [(SOME _) #t] [NONE #f])) 

<function> : (forall ['a] ((option 'a) -> bool)) 

-> (lambda (z) (case z [(SOME (PAIR '() _)) #t] [NONE #f])) 
Warning: case expression does not match values of this form: 


(SOME (PAIR (cons _ _) _)) 


<function> : (forall ['a 'b] ((option (pair (list 'a) 'b)) -> bool)) 
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Molecule, abstract data types, and modules 


[The programmer] is concerned with the way his program 
makes use of the abstractions, but not with any 

details of how those abstractions may be realized. ... 

A structured programming language must provide a 
mechanism whereby the language can be extended to 
contain the abstractions which the user requires. 


Barbara Liskov and Stephen Zilles, 
Programming with Abstract Data Types 


In the languages we’ve examined so far, when we have a high-level problem like 
“see if a list contains an interesting element,” we can define a high-level, problem- 
specific function like exists?. But we can't yet define problem-specific data; 
no matter what problem we’re working on, our code is written in terms of repre- 
sentations like numbers, symbols, Booleans, lists, S-expressions, and constructed 
data. We should hope for better; if we’re implementing high-level actions like “find 
the rule in the table,” “multiply two 50-digit numbers,” or “stop recording when the 
event is over,’ then our code should be written in terms of abstractions like tables, 
large numbers, and events. Such abstractions can be defined by the language fea- 
tures described in the last two chapters of this book. 

The ability to define a new form of data, hiding its true representation from 
most code, is called data abstraction. Data abstraction is typically supported by ab- 
stract data types, objects, or a combination thereof. Using abstract data types, code 
is organized into modules, and only a function that is inside a module has access to 
the representation of values of that module’s abstract types. Using objects, code is 
organized into methods, and only a method that is defined on an object has access to 
the representation of that object. Abstract data types and modules are described in 
this chapter, which also describes some proven strategies for designing programs 
that use data abstraction. Objects and methods are described in Chapter 10. 

Why use data abstraction? It enables us to replace a representation with a new 
one, without breaking code; it helps limit the effects of future changes; and it pro- 
tects vulnerable representations from most careless or faulty code. For example, 


* The Linux kernel (and much else besides) is built by a program called Make. 
Make works by composing rules, which say how to build the components of a 
system. In Make’s initial implementation, rules were kept on an association 
list, which was fine, because Makefiles started out small: a Makefile con- 
tained at most one or two dozen rules. But Make’s author, Stuart Feldman, 
decided that for the first public version, craftsmanship demanded a hash ta- 
ble. Because the representation was hidden, it was easy to replace. 


Did it matter? When Feldman was asked to help debug a Makefile, he found 
thousands of rules. Luckily, the hash table performed well—far better than 
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the association list would have. Data abstraction enabled Feldman to replace 
one representation with another, without breaking code. 


My digital video recorder is programmed to record a ball game. Thanks to 
real-time game information, it records until the game is actually over, not 
just until the end of the game’s scheduled time slot. But real-time game in- 
formation often changes format; first it’s HTML, next it’s XML, now it’s JSON. 
Its content changes, too. These changes break my code, but I limit their ef- 
fects by defining an abstraction that tells me only who’s playing, whether the 
game has started, and whether it’s over. Only the abstraction knows the ever- 
changing representation of game information, and when the representation 
changes again, I can update my code quickly—without missing any games. 


In Chapters 1 to 3, two Names with different pointer values are guaranteed to 
point to different strings. This property is an invariant property of the data 
structure defined in file name.c. It is guaranteed only because the represen- 
tation of struct Name is hidden. Because the representation is hidden, code 
outside of name.c can create a Name only by calling strtoname, which guar- 
antees that each such name respects the invariant. Data abstraction protects 
the invariant, so faulty outside code can’t invalidate it. (Malicious code could 
invalidate the invariant by using memcpy or similar skullduggery.) 


Abstractions and invariants are the key elements in a proven strategy for designing 
with data abstraction, which is sketched in Section 9.6. 

Data abstraction can be accomplished using abstract types, objects, or both, but 
because abstract types are easier to learn, they are where we begin. Every abstract 
type is defined in some module, and its representation is exposed only to functions 
that are defined in that same module. Functions defined outside the module, which 
are called client functions, know only the name of the abstract type, not its repre- 
sentation. When a client function wants to create, observe, or mutate a value of 
abstract type, it must call a function defined inside the module. Types and func- 
tions defined in a module are visible to client code only if they are named in the 
module’s interface; such types and functions are said to be exported. 

Abstract data types militate toward a particular programming style, which you 
already have some experience with: in the C interpreters in Chapters 1 to 4, you 
have seen abstract types Name and Env, as well as C’s built-in FILE *. Primitive types, 
such as Typed wScheme’s int or C’s float and double, also behave like abstract 
types—that is, all we know about these primitive types are their names. To work 
with primitive types, we must use primitive functions, which have privileged access 
to the representations. 

In this book, abstract data types are illustrated by the programming language 
Molecule, which borrows from the Modula, ML, and CLU families of languages. 
Molecule’s key feature is abstract data types, but to enable you to program inter- 
esting examples, Molecule provides two other notable features. First, it supports 
polymorphism through generic modules. Second, to enable check-expect testing 
and a read-eval-print loop without violating abstraction, Molecule overloads names 
like = and print, among others. 

Acaution: When programs are built from modules and are full of abstractions, 
programming feels different. Molecule emulates languages like Ada, CLU, and 
Modula-3, and unlike Scheme, ML, and Smalltalk, these languages don’t help you 
knock out small, interesting programs quickly—they help you build large systems 
that can evolve. But in one chapter of a survey book, we can't build a large system, 
and we can’t realistically show how software evolves. To appreciate the software- 
engineering benefits that modules provide, you must use your imagination. 


Language design for modules 


A language for learning about modules should include distinct syntax for inter- 
faces and implementations, a clean type theory, a relatively simple core layer, 
and support for generic (parameterized) modules. Unfortunately, no single lan- 
guage found in the wild meets all three criteria. To create a language for learn- 
ing about modules, I borrowed from the Modula family, which pioneered sep- 
arately compiled interfaces and implementations, from Xavier Leroy’s formu- 
lation of ML modules, which exemplifies simple, clean generic modules with 
modular type checking, and from CLU, which demonstrated the benefits of ab- 
stract types. Because the name “Moleclu” would be hard to pronounce, the re- 
sulting language is called Molecule. 


9.1 THE VOCABULARY OF DATA ABSTRACTION 


To program with data abstraction, we must understand our programs at two levels: 
the concrete level, which explains details that appear in the code, and the abstract 
level, which explains the ideas that drive the code’s design. Relating these levels 
requires some vocabulary. 

The key word is abstraction. An abstraction is the thing that we want to write 
most of our code in terms of: a ball game, a large number, a table, or what have you. 
Narrowly, “an abstraction” is the thing that a value of abstract type stands for. 
An abstraction isn’t code; it’s an idea that tells us what code is doing. An abstraction 
might be described using mathematics or metaphor. 

Representation describes the data in the code. For example, a ball game in my 
video recorder is represented by a JSON object of unholy complexity. 

Access to representation determines whether code operates at an abstract level 
or a concrete level. Code that can see only an abstraction is abstract; it is called 
client code. Code that can see the representation of an abstraction is concrete; it is 
part of the abstraction’s implementation. 

When using abstract data types, an implementation is called a module. Or it 
should be—in practice, modules are called different things in different languages. 
For example, in the Modula family a module is an “implementation module,” in 
Ada it’s a “package body,” and in Standard ML it’s a “structure.” In Molecule, it’s a 
module. 

A module grants access to its clients through an interface. Aninterface describes 
the abstractions implemented by a module and the operations on the abstractions. 
In the world of abstract data types, operations are functions; in the world of objects, 
operations are methods. Either way, operations described in an interface are said 
to be exported or public. For example, the operations exported by the ball-game 
module are to get a list of games from the Internet and to ask a single game who is 
the home team, who is the away team, if the game has started, or if it is over. 

The word “interface” always means “what you need to know to use a module.” 
But what you truly need to know depends on what you want to do. If you want to 
write client code, you need to understand the abstraction, and you need to know the 
complete specification of every operation: its name, its type, and howit is supposed 
to behave. This information is an “application program interface” (API). Behavioral 
specifications are usually written informally, in natural language; they might be 
found on a web page of developer documentation, or for an older interface, on a 
Unix man page. When I want to emphasize this meaning of “interface,” I use “API” 
or “complete API.” 
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Table 9.1: Examples of qualified names 


Name Component 


IntArray.t The type of an array of integers 
IntArray.size Function that gives the size of an array of integers 
IntArray.new Function that creates a new array of integers 


Int.t The type of an integer 
Int.< Function that compares two integers 
Bool.t The type of a Boolean 


If you just want code to compile, then all you need to know are the names and 
types of the operations. This information is usually written formally, in a program- 
ming language, where it can be checked by an interpreter or compiler; the language 
construct used to express it is also called an “interface.” Or it should be—in prac- 
tice, interfaces, which are bit like C’s .h files, are called different things in different 
languages. For example, in the Modula family an interface is a “definition module,” 
in Ada it’s a “package specification,” in Standard ML it’s a “signature,” and in Java 
it’s an “interface.” In Molecule, it’s a module type. When I want to emphasize this 
meaning of “interface,” I use “module type.” 

Finally, “abstraction” often refers not just to what a value of abstract type stands 
for, but also to the things around it. When a programmer says, “I’m going to design 
an abstraction,” they mean at least the abstraction and its complete API, and maybe 
also an implementation. 


9.2 INTRODUCTION TO MOLECULE, PART I: WRITING CLIENT CODE 


To introduce Molecule, I present an example of client code—code that uses an ab- 
straction. The abstraction, which is implemented by a module and specified by an 
interface, is “array of integers.” The client code finds the smallest integer in such 
an array. 


Modules, components, and qualified names 


Client code refers to types and operations that are defined in a module. Each such 
defined thing is called a component. Client code may refer to any component that 
is exported by a module’s module type. Every component has a name, and every 
module also has a name, and the two together are used to form the component's 
qualified name. The qualified name is the name of the module, followed by a dot, 
followed by the name of the component, as in IntArray .new, which is an operation 
that creates a new array. If you are used to dot notation for the members of a struct 
or record, as in C, you may think of a module as a sort of glorified record, which 
includes not only value components but also type and module components. 

Some examples of qualified names appear in Table 9.1. The t in Int.t is 
conventional: when a module exports one, primary abstract type—like an array, 
a list, or a hash table, for example—the abstract-type component is conventionally 
called t. For example, Int.t is the type of integers, IntArray.t is the type of arrays 
of integers, IntList.t is the type of lists of integers, and so on. This convention is 
borrowed from Modula-3 (Nelson 1991; Horning et al. 1993; Hanson 1996). 

The .t convention is useful, but for continuity, you can continue to refer to 
primitive types using the unqualified names that are used in other chapters: int, 


bool, sym, and unit. In Molecule, these names are defined as type abbreviations: 
529a. (predefined Molecule types, functions, and modules 529a) = 529b> 
(type int Int.t) 
(type bool Bool.t) 
(type unit Unit.t) 
(type sym Sym.t) 


What any client must know: An example interface 


Client code depends on a complete API, including a description of the abstraction, 
a module type, and a behavioral specification of every exported operation. The ex- 
ample client below depends on the IntArray module, whose abstraction is an array 
of integers. The abstraction, which I hope is familiar, can be described using this 
metaphor: A value of type IntArray.t (or just “an array”) is a sequence of boxes, 
each of which holds a value of type int. 

The IntArray module implements the ARRAY module type, which is part of the 
initial basis of Molecule and is defined here: 


529b. (predefined Molecule types, functions, and modules 529a) += <1529a 540a> 
(module-type ARRAY 
(exports [abstype t] 77 an array 
[abstype elem] ;; one element of the array 
[new : (int elem -> t)] 
[empty =: ( -> t)] 
[size : (t -> int)] 
[at : (t int -> elem) ] 


[at-put : (t int elem -> unit)])) 


The complete API for arrays specifies not just the type but also the behavior of each 
exported operation. Crucially, the specifications are written in terms of the ab- 
straction (the box metaphor). 


* Calling (new nv) creates an array of n boxes, numbered from 0 to n — 1. 
Each box holds the value v. 


* Calling (empty) creates a new, empty array with no boxes in it. 
* Calling (size A) tells us how many boxes are in array A. 
* Calling (at A 7) tells us what value is in box i of array A. 


* Calling (at-put Ai v) puts value v into box i of array A. 


The meaning of a module type 


In Molecule, as in OCaml and Standard ML, a module type has its own identity, 
independent of any module that might implement it. And the ARRAY module type 
may be implemented by many modules: array of integers, array of Booleans, array 
of symbols, and so on. A module type is a species of promise, which any implemen- 
tation must redeem. The promise is to provide each of the exported components 
listed in the module type. Therefore, a module can implement the ARRAY module 
type if it provides two types t and elem, plus the five functions new, empty, size, 
at, and at-put—all with the correct types. 

In Molecule, a module can implement more than one module type. The most 
specific module type that a module can implement is specified when the module 
is defined. For IntArray, the module type ARRAY is not quite specific enough: 
it doesn't say what elem is. To write a client that finds the smallest integer in 
an array, we need to know not only that IntArray.at returns a value of type 
IntArray.elem; we also need to know that type IntArray.elem is the same as 
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type int. In Molecule, elem’s identity is revealed by a manifest-type declaration: 
[type elem int] 


The IntArray module implements both the ARRAY module type and a module 
type that reveals elem, as confirmed by these unit tests: 
530a. (interface checks of predefined modules 530a)= 540b > 


(check-module-type IntArray ARRAY) 
(check-module-type IntArray (exports [type elem Int.t])) 


Example client code 


Knowing that IntArray implements module type ARRAY with type elem equal to int, 
client code can use the exported operations, referring to them by their qualified 
names. As an example, I use IntArray.new to make an array: 


530b. (transcript 530b)= 530¢ > 
-> (val a (IntArray.new 4 99)) 
[99 99 99 99] : IntArray.t 


To find the smallest element in a nonempty array of integers, I define function 
smallest-int, which uses exported operations IntArray.at and IntArray.size: 


530c. (transcript 530b) += <1530b 530d> 
-> (define int smallest-int ([a : IntArray.t]) 
(let ([smallest (IntArray.at a 0)] 
{i 1] 
[n (IntArray.size a)]) 
(while (Int.< i n) 
(when (Int.< (IntArray.at a i) smallest) 
(set smallest (IntArray.at a i))) 
(set i (Int.+ i 1))) 
smallest) ) 
smallest-int : (IntArray.t -> Int.t) 


Molecule code is quite similar to Typed psScheme code, but as illustrated here, Mol- 
ecule has some additional features that simplify procedural programming. One is 
the when form, which is “an if with no else”; its body is executed only when the 
condition holds. Another is that the body of a let expression, a while loop, or 
a function definition may be a sequence of expressions. At parse time, each such 
sequence is wrapped in an implicit (begin ---). 
The smallest-int function can be used with our example array a. And mutat- 

ing a can change the outcome: 
530d. (transcript 530b) += <1530c 542> 

>a 

[99 99 99 99] : IntArray.t 

-> (smallest-int a) 

99 : Int.t 

-> (IntArray.at-put a 1 55) 

-> (IntArray.at-put a 2 33) 

-> (smallest-int a) 

33 : Int.t 


For more examples of array computations, see Exercises 1 and 2. 


9.3 INTRODUCTION, PART II: IMPLEMENTING AN ABSTRACTION 


The hard part of programming with data abstraction is thinking up good abstrac- 
tions and their specifications—once an abstraction is specified, implementing it is 


comparatively easy. I would love to demonstrate using IntArray, but IntArray is 
not actually implemented in Molecule; the array operations are implemented by 
primitive functions, which are implemented using ML code in the interpreter. In- 
stead, I demonstrate with a module that implements a new, less useful abstraction: 
a point in the two-dimensional plane. 


Interface and client code for a point abstraction 


A complete API for two-dimensional points includes a module type that lists the 
exported operations. Each operation's behavior is specified in a comment. 


581a. (2dpoint.mcl 531a)= 532b > 
(module-type 2DPOINT 
[exports 

[abstype t] ;; a point on the plane 

[new : (int int -> t)] ; takes (X, Y) coordinates and 
; returns a new point 

[get-x : (t -> int)] ; return x coordinate 

[get-y : (t -> int)] ; return y coordinate 

[quadrant : (t -> sym) ] ; return ‘upper-right, ‘upper-left, 
: "lower-right, or 'lower-left 

[print : (t -> unit)] ; print characters representing the point 


[reflect : (t -> unit)] ; reflect the point through the origin 
[rotate+ : (t -> unit)]]) ; rotate point 90 degrees CCW about origin 


As seen by the types and the comments, the abstraction is mutable: reflection and 
rotation change the state of an existing point. 

The API can be illustrated by some simple examples. First, some bureaucracy: 
load the code from file 2dpoint.mcl, then use overload to tell the interpreter to 
print points using function 2Dpoint.print: 
531b. (2Dpoint transcript 531b)= 531¢> 

-> (use edpoint.mcl) 
module type 2DPOINT = ... 


-> (overload 2Dpoint.print) ;; tell the interpreter how to print a 2Dpoint.t 
overloaded print : (2Dpoint.t -> Unit.t) 


The overload directive is described in Section 9.4.3 below. 

For our example, I create a point p and then change its state twice. All three 
states are depicted in Figure 9.2. Initially, p has coordinates (3, 4), which puts it in 
the upper-right quadrant of the plane. 


531c. (2Dpoint transcript 531b) += <1531b 531d> 
-> (val p (2Dpoint.new 3 4)) 
(3, 4) : 2Dpoint.t 
-> (2Dpoint.quadrant p) 
upper-right : Sym.t 


When I rotate p about the origin, it moves to the upper-left quadrant. 


531d. (2Dpoint transcript 531b) += <1531c 532a> 
-> (2Dpoint.rotate+ p) 
-> (2Dpoint.quadrant p) 
upper-left : Sym.t 
->p 
(-4, 3) : 2Dpoint.t 
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UPPER LEFT UPPER RIGHT 
after rotatet, initially, p = (3, 4) 
p= (—4, 3) 


after rotate+ and reflect, 
p= (4, —3) 


LOWER LEFT LOWER RIGHT 


Figure 9.2: Three states of a mutable 2Dpoint 


Reflecting p through the origin negates both coordinates, leaving p in the lower- 
right quadrant. 
532a. (2Dpoint transcript 531b) += 531d 
-> (2Dpoint.reflect p) 
->op 
(4, -3) : 2Dpoint.t 
-> (2Dpoint.quadrant p) 
lower-right : Sym.t 


Implementation of the point abstraction 


To implement the point abstraction, I define a new module named 2Dpoint. 
The definition identifies 2DPOINT as the interface that 2Dpoint is supposed to im- 
plement: 
532b. (2dpoint.mcl 531a) += <153la 
(module [2Dpoint : 2DPOINT] 
(definition of type t inside module 2Dpoint 533a) 
(definitions of functions inside module 2Dpoint 533b) 
) 
The use of 2DPOINT here does more than just say, “module 2Dpoint implements 
the 2DPOINT interface.” It also seals the module. Sealing prevents information from 
escaping; only what’s exposed in the module type is visible. 


* The representation of the abstract type 2Dpoint.t is hidden. 


* Components that are not exported are hidden. 


The sealing is checked by the Molecule interpreter, which confirms that the 
2Dpoint module redeems the promises made by the 2DPOINT module type. Each 
promise made by a module type is redeemed as follows: 

+ Every abstract type is given a defined representation. 

+ Every manifest type is defined to be equal to the type specified. 


+ Every exported variable, function, or value constructor is defined with the 
type specified. 


The body of a module is a sequence of definitions. In our example, the first 
definition is the definition of type t. I’ve chosen an algebraic data type (Chapter 8). 
533a. (definition of type t inside module 2Dpoint 533a)= (532b) 

(data t [XY : (int int -> t)]) 
This definition says that a value of type 2Dpoint.t is constructed by applying value 
constructor XY to two values of type int. In Molecule, by contrast with zML, con- 
structed values are mutable; the value constructor allocates two fresh, mutable lo- 
cations and stores an argument in each one. These locations become accessible 
through pattern matching in a case expression. 

Value constructor XY is used in function 2Dpoint . new to create a new point from 
the given coordinates x and y. 


533b. (definitions of functions inside module 2Dpoint 533b)= (532b) 533c > 
(define t new ([x : int] [y : int]) 
(XY x y)) 


Because this code is inside the 2Dpoint module, it can use constructor XY. Because 
the constructor is not exported by the interface, client code can’t use it. 
Inside the module, value constructor XY can also be used for pattern matching, 
as it is in functions get-x and get-y. 
533c. (definitions of functions inside module 2Dpoint 533b) += (532b) <533b 533d> 
(define int get-x ([p : t]) 
(case p [(XY x y) x])) 


(define int get-y ([p : t]) 
(case p [(XY x y) y])) 
Now let’s see how a point is mutated. To reflect a point through the origin, 
I negate both x and y coordinates, using function Int.negated from Molecule’s 
predefined Int module. The pattern matching on point p makes names x and y 
refer to the mutable locations holding p’s coordinates. Like the locations named by 
other variables, these locations can be set. 
533d. (definitions of functions inside module 2Dpoint 533b) += (532b) <1533c 533e> 
(define unit reflect ([p : t]) 
(case p [(XY x y) (begin 
(set x (Int.negated x)) 
(set y (Int.negated y)))])) 


The rotate+ operation also mutates a point, replacing x with —y and y with x. 
To calculate new values of x and y before any location is mutated, I use a let form: 


533e. (definitions of functions inside module 2Dpoint 533b) += (532b) 533d 533f> 
(define unit rotate+ ([p : t]) 
(case p [(XY x y) (let ([new-x (Int.negated y)] 
[new-y x]) 
(set x new-x) 
(set y new-y))])) 


I print a point using Descartes’s classic notation. To print parentheses and 
whitespace, I use values and the print operation from the predefined module Char. 


5336. (definitions of functions inside module 2Dpoint 533b) += (532b) 1533e 534> 
(define unit print ([p : t]) 
(Char.print Char.left-round) 
(Int.print (get-x p)) 
(Sym.print ',) 
(Char.print Char.space) 
(Int.print (get-y p)) 
(Char.print Char.right-round) 
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The code uses a little syntactic sugar: the body of a define may be a sequence of 
expressions, which are implicitly wrapped in a begin. 

I complete the implementation with the quadrant operation. A point on a 
boundary between quadrants is considered to be in the quadrant on the positive 
side of the boundary. 

534. (definitions of functions inside module 2Dpoint 533b) += (532b) <1533f 
(define sym quadrant ([p : t]) 
(case p [(XY x y) (if (= x 0) 
(if (>= y 0) ‘upper-right 'lower-right) 
(if (>= y 0) ‘upper-left ‘'lower-left))])) 


9.4 THE MOLECULE LANGUAGE 


The examples above illustrate Molecule’s key mechanisms: each abstraction is 
specified by a module type (the interface), which is implemented by a module (the 
implementation). A module type specifies the names, natures, and types of a mod- 
ule’s components; a module defines those same components. In the syntax, modules 
and module types account for the forms in Molecule’s module layer; the remaining 
forms, which express types, expressions, and definitions, make up Molecule’s core 
layer. Organizing the language in two layers has significant benefits: 


* The core layer is stuff you already know from Chapters 6 and 8: it’s Typed 
pScheme plus algebraic data types from jsML. And the core-layer part of the 
type system is a lot like Typed Impcore’s type system; there’s nothing fancy. 


* Only the module layer has to worry about enforcing data abstraction. And 
it’s reusable: the module layer, which is based on the work of Leroy (2000), 
could be grafted onto a different core layer and it still do its job. 


To keep the type system as simple as possible, both layers share a single name 
space (environment), which is used for everything: values, types, and modules. 
A name that originates in the core layer may stand for a mutable location holding 
a value, as in Typed Impcore or Typed pwScheme, or it may stand for a type; type 
names are not relegated to a separate environment as they are in Typed jsScheme. 
A name that originates in the module layer may stand for a module or a module 
type. Finally, a name may be overloaded (Section 9.4.3), standing for a set of values 
of different types. 


9.4.1 Molecule’s core layer 


Molecule’s core layer is very much like Typed zScheme (Chapter 6). The core layer 
combines familiar elements (Chapters 6 and 8) in new ways: 


* The core layer uses a monomorphic type system—polymorphism is imple- 
mented in the module layer, using generic modules. 


* Like Typed Scheme, Molecule provides atomic data (symbols, numbers, 
and Booleans) and first-class functions. Like Typed Impcore, Molecule 
provides primitive arrays. Like ML (Chapter 8), Molecule provides con- 
structed data using algebraic data types, which, in one tidy package, support 
“struct/union,” “record/variant,’ and “sum of products” programming. And 
in Molecule, constructed data can be mutated. 


* Molecule’s core layer includes the familiar syntactic forms from Impcore 
and pScheme: set, if, while, begin, function application, let forms, and 


lambda. For deconstructing constructed data, it also includes the case form 
from ML. And to better support procedural programming, it provides syn- 
tactic sugar for sequencing and conditionals. 


Each of these aspects is presented in more detail below. 


Core-layer types 


Molecule’s support for polymorphism resides in the module layer; the core layer 
is monomorphic. A core-layer type is either a type constructor or a function 
type—there are no type parameters, no type variables, and no polymorphic types. 
The typing rules are exactly what you would expect from Typed jScheme, and they 
are very close to Typed Impcore. 

Molecule’s core layer includes algebraic data types like those in jsML (Chap- 
ter 8), but as in the rest of the core layer, there are no type parameters. Every 
algebraic data type has kind «. 

Like “ML but unlike Typed «Scheme and Typed Impcore, Molecule enables 
programmers to create new type constructors. A new type constructor can be cre- 
ated by a data form, as in jsML. And, uniquely to Molecule, a new type constructor 
can be created by sealing a module (typing rules in Section 9.8). 


Core-layer values 


Molecule has all the values found in jzScheme, plus a form of constructed data. 
Unlike in 4ML, where a value constructor carries other values, in Molecule, a value 
constructor carries mutable locations. A constructed value is introduced either by 
using a value constructor alone, like #f, or by applying a value constructor to ar- 
guments, as in (XY 3 4). When a value constructor is applied, a fresh, mutable 
location is allocated for each argument. 

A constructed value is eliminated via pattern matching in a case expression. 
When a pattern names the argument of a value constructor, that name refers to the 
mutable location that is carried with the value constructor. Such a location can be 
mutated using set, as in the implementation of rotate+ in Section 9.3. 


Core-layer syntax and syntactic sugar 


The core layer’s concrete syntax is shown in Figure 9.3 on the next page. It is 
the same as the syntax for Typed pjScheme (Figure 6.3, page 353), except for these 
changes: 


The exp form that names a variable or function may use a qualified name, 
not only a simple name. Similarly, the type-exp form that names a type con- 
structor may use a qualified name. 


To support algebraic data types, Molecule includes the data definition form, 
the case expression form, and the pattern syntactic category from ML (Fig- 
ure 8.1, page 467). 


To support operator overloading, Molecule includes an overload definition 
form (Section 9.4.3, page 543). 


Because its core layer is monomorphic, Molecule does not have Typed 
pScheme’s type-lambda or @ expression forms. And Molecule does not have 
Typed ~wScheme’s type variables or forall types. 


A literal S-expression evaluates to an array, not to a list. 
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def ::= (val variable-name exp) 


(val-rec [variable-name : type-exp] exp) 

(define type-exp function-name c{ [variable-name : type-exp] }) exp) 
(data type-name { [value-constructor-name : type-exp] }) (from ML) 
exp 

(overload { qualified-name} ) 

(use file-name) 

unit-test 


unit-test ::= (check-expect exp exp) 


(check-assert exp) 
(check-error exp) 
(check-type exp type-exp) 
(check-type-error def) 


exp = literal 


qualified-name (replaces variable-name form) 
(set variable-name exp) 

(if exp exp exp) 

(while exp exp) 

(begin {exp}) 

(exp { exp} ) 

(let-keyword ( { [variable-name exp] } ) { exp} ) 

(letrec [ { ([variable-name : type-exp] exp) al {exp}) 

(lambda c{ [variable-name : type-exp] }) exp) 


(case exp { [pattern exp] }) (from ML) 
let-keyword ::= let | let* 
qualified-name ::= name | qualified-name.name (names module, type, or variable) 
(@m qualified-name { qualified-name} ) 
pattern = variable-name 
value-constructor-name 
(value-constructor-name { pattern} ) 
type-exp = qualified-name (replaces type-constructor-name) 
({ type-exp} —> type-exp) 
literal = numeral | #t | tf | ' S-exp | (quote S-exp) 
S-exp = literal | symbol-name | ({S-exp}) 
numeral ::= token composed only of digits, possibly prefixed with a plus 


or minus sign 


value-constructor-name 


*name 


i= cons | 6) | atoken that begins with # or with a capital letter 
or with make- 

::= a token that is not a bracket, a dot, a numeral, a value- 
constructor-name, or one of the “reserved” words shown in 
typewriter font 


(Compare it with Typed piScheme; see Figure 6.3, page 353.) 


Figure 9.3: Molecule’s core layer 


modtype ::= modtype-name 

(exports { dec}) 

(allof {modtype}) 

c{ [module-name : modtype] } --m-> modtype) 


dec ::= [abstype type-name] 

[type type-name type-exp) 

[name : type-exp] 

[module [module-name : modtype]] 


def = (module-type modtype-name modtype) 

(module [module-name : modtype] { def }) 

(generic-module [module-name : modtype] { def }) 

(module [module-name : modtype] qualified-name) (sealing) 
(module module-name qualified-name) (abbreviation) 
(type type-name type-exp) 


unit-test ::= (check-module-type qualified-name modtype) 


Figure 9.4: Molecule’s module layer 


modtype *::= (exports-record-ops type-name c{ [variable-name : type-exp] })) 


def x ::= (record-module module-name type-name 
( { [variable-name : type-exp] } )) 


* (define type-exp function-name c{ [variable-name : type-exp] }) { exp}) 


exp x i:= (assert exp) 

(&& { exp}) 

Ci {exp}) 

(when exp {exp}) 

(unless exp {exp}) 

(while exp { exp}) 
((1et|let*|letrec) (...) {exp}) 


+ + + + + 


Figure 9.5: Syntactic sugar 


In addition to familiar syntactic sugar for && and | |, Molecule provides syn- 
tactic sugar that helps with procedural programming (Figure 9.5). Forms 
when and unless implement one-way conditionals, and each of these forms, 
as well as the while, let, and define forms, supports a body that is a se- 
quence of expressions, not just a single expression. 


The core-layer definition forms shown in Figure 9.3 are supplemented by module- 
layer definition forms, which appear in Figure 9.4 and are described below. 


Core-layer evaluation 


The core-layer forms are evaluated as in jsScheme or WML, with extra support for 
overloading (Section 9.4.3). The new forms, which are syntactic sugar, are evalu- 
ated as follows: 


* Theassert form evaluates its exp, and if the expis not true, halts the program 
with a checked run-time error. 
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* The when form evaluates its condition, and if the condition is true, evaluates 
every expression in the body, in sequence. The unless form is similar, except 
the body is evaluated only if the condition is false. 


* The body of an extended while, let, or define form is evaluated as if 
wrapped in begin. 


9.4.2 Molecule’s module layer 


Molecule’s module layer expresses both module types and modules (Figure 9.4). The 
sheer number of modtype and def forms looks intimidating, but most code needs 
only the exports form of modtype and the first three forms of def: one form to 
define a module type, one to define an ordinary module, and one to define a ge- 
neric module. The complete list of module-related forms, which is summarized in 
Table 9.6, is best examined through the type-theoretic lens of formation, introduc- 
tion, and elimination. 


Formation of module types 


A module type both controls access to a module and makes promises on the mod- 
ule’s behalf. A module type can be referred to by name, but its ultimate definition 
takes one of three forms: 


+ An export list, written using exports, which lists the module’s components, 
to which it promises access 


+ A module-arrow type, written using the module arrow --m->, which describes 
the parameters and the result type of a generic module 


+ An intersection type, written using allof, which promises every component 
that is listed in any of the intersected module types 


Each of these forms is described in detail below. 


Export lists 


An export list specifies the components exported by a module. Each component is 
specified by a declaration. Like a field of a record, a component of a module has a 
name, but unlike a field of a record, a component may be not just a value but also 
a type or another module. 


* A value component is a variable or a function, and it is declared by giving its 
name and type, using the same syntax we use to give the name and type of a 
formal parameter to a function. For example, 


538a. (example module components 538a) = 538b > 
[size : (t -> int)] 
[at : (t int -> elem)] 


+ A type component may be either abstract or manifest. An abstract type has 
a definition, but its definition is hidden; only its qualified name is known. 
An abstract type is unique and is distinct from any other type, even if the 
other type happens to have the same definition (like Int.t and Char.t). 
A manifest type exposes its definition, so clients know not only that the type 
component exists but also how itis defined. The qualified name ofa manifest 
type is treated as an abbreviation for its definition. For example, 
538b. (example module components 538a) += <1538a 539a> 

[abstype t] ; abstract type 
[type elem Elem.t] ; manifest type (abbreviation for Elem.t) 


Table 9.6: Some syntactic forms of Molecule 


Definition form Declaration form Expression form 
Module module (module [M : 7 ]) none! (2nd class) 
Generic module generic-module none(notacomponent) none! (2nd class) 
Module type module-type none (notacomponent) (exports---) 
Type type, data [abstype?t],[typet7] (asin ML) 
Value val, define [ore] (as in wML) 


* A module component is a nested module. Like a value component, it is de- 
clared with its name and its module type, but the declaration uses the key- 
word module. For example, 
539a. (example module components 538a) += <1538b 

(module [Move : (exports [type t] 
[to-string : (t -> String.t)] 
[of-string : (String.t -> t)])]) 


To contrast it with a generic module, a module that exports components can be 
called an exporting module. 

A module type is well formed if every type that is used is defined and if every 
component is uniquely defined. In detail, 


* In an export list, before a type component can be used to give the type of a 
value component, the type component must be declared. 


* Within a single export list, no component may be declared more than once. 


* The types used in every declaration must be well formed. 


The formalities appear in Section 9.8.6. 
A module type can be named using a module-type form (Figure 9.4): 


539b. (example module-layer definitions 539b) = 
(module-type EXPORTS-T (exports [abstype t])) 


Module introduction: Definition forms for exporting modules 


A module type only makes promises—it doesn't deliver any values, types, or mod- 
ules. To deliver on the promises requires a module, which is defined using one 
of the module forms from Figure 9.4. An exporting module is typically defined 
by giving its name M, its module type 7, and a sequence of definitions, like so: 
(module [M : J ] d,--- d,). The definition of MM is well typed only if all the d,’s 
are well typed and if M provides all the components listedin 7. And the definition 
seals module M with type 7. Sealing limits access to the components defined by 
definitions d,--- d,: outside of M, the only components that can be named are 
those mentioned in 7. And if any of the type components is declared as an abstract 
type, its definition is hidden. 

Exporting modules can also be defined using two other forms. First, an exist- 
ing module M’ may be sealed using the form (module [M : T ] M’). New mod- 
ule M has the same components as existing module M’, but only components 
exported by module type 7 are visible. And if any type component t is declared 
as abstract in 7, then sealing gives type /.t a new identity that is distinct from 
M’.t. (In the language of Chapter 8, sealing is generative.) Second, an existing 
module may be abbreviated, without sealing, using the form (module MM’), as 
in (module IR (@m Ref Int)). Such abbreviations are used primarily for instances 
of generic modules, which are discussed below. 
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Module elimination: Qualified names 


Client code can observe or interrogate a module in only one way: it can name 
a component. The component's qualified name is formed by concatenating the 
name of the module, a dot, and the name of the component. Qualified names are 
used in many languages, including Ada, CLU, Haskell, Java, OCaml, Modula-3, and 
Standard ML. In Molecule, as in most of these languages, a qualified name like 
IntArray.at selects a component from a module. Qualified names can also in- 
stantiate generic modules, as described below. 


Generic modules 


A good module can embody a lot of craft—think about the engineering that goes into 
a balanced search tree or a good hash table. Such engineering should be reusable, 
and you already know a suitable mechanism: higher-order, polymorphic functions. 
But at this scale, lambda and type-lambda are awkward; they work with individual 
values and types, and the unit of reuse should be the module. To support polymor- 
phism with modules, Molecule provides generic modules. 

A generic module takes one or more other modules as formal parameters, and it 
produces a module as its result. By taking modules as parameters, generic modules 
provide, in one mechanism, the capabilities of higher-order functions (functions as 
parameters, as with lambda) and parametric polymorphism (types as parameters, 
as with type-lambda). 

A parameter of a generic module may not itself be generic. This sort of restric- 
tion, which says that the parameter to a polymorphic thing may not itself be poly- 
morphic, makes the polymorphism predicative. Predicativity can simplify a type 
theory considerably, so predicative polymorphism is common. For example, the 
Hindley-Milner type system used in core ML is predicative, and so are systems for 
other languages that support generic modules, including CLU, Ada, and Modula-3. 
Type systems in which type parameters are not restricted, like Typed jScheme, are 
called impredicative. 

In Molecule, the type of a generic module is written like a function type, except 
that each formal parameter gets a name (so that later parameters and the result type 
may refer to it), and the parameters are separated from the result type by the mod- 
ule arrow --m->. For example, the type of Molecule’s predefined, generic Array 
module is as follows: 
540a. (predefined Molecule types, functions, and modules 529a) += <1529b 541b> 

(module-type GENERIC-ARRAY 
([Elem : (exports [abstype t])] --m-> 


(exports [abstype t] 77 an array 
[type elem Elem.t] ;; one element of the array 
[new : (int elem -> t)] 
[empty =: ( -> t)] 
[size $1 fh Se ants] 
[at : (t int -> elem) ] 


[at-put : (t int elem -> unit)]))) 


The elem type in the result module is known to be equal to the type t in the param- 
eter module, Elem. That crucial identity can be expressed only because the formal 
parameter is named. 

Module type GENERIC-ARRAY is the type of the primitive module Array: 


540b. (interface checks of predefined modules 530a) += <1530a 
(check-module-type Array GENERIC-ARRAY) 


A module-arrow type is well formed only if the module type of each formal 
parameter describes an exporting module, not a generic module—that’s the pred- 
icative polymorphism. The module type of each parameter must be well formed, 
and the module type of the result must also be well formed. The module type of 
the result may refer to formal parameters, like Elem in the example above. And the 
module types of later parameters may refer to earlier parameters.! 

A generic module is introduced using the same definition form as an exporting 
module, except that it uses the keyword generic-module, and the module type used 
to seal it must be a module-arrow type. For an example, see the definition of generic 
module ArrayHeap in chunk 552a. 

A generic module is eliminated by instantiating it. Instantiation creates an 
exporting instance of a generic module. The concrete syntax resembles the in- 
stantiation of a polymorphic value in Typed Scheme, but to remind us of the 
distinction between a generic module in Molecule and a polymorphic value in 
Typed Scheme, a generic instantiation is written using keyword @m. For example, 
the predefined module String is an instance of the generic Array module: 
541a. (definition of module String 541a)= 

(module String (@m Array Char)) 


The instance is pronounced “Array at Char.” 

An instance of a generic module also plays a second role: an instance of a ge- 
neric module counts as a qualified name. This quirk of Molecule’s type system, 
which is explained in depth in Section 9.8.7, supports a simple algorithm for type 
checking with abstract types. To get the right intuition, think of the instance as be- 
ing like the application of a type constructor, like (array char) in Typed Impcore. 


Intersection types 


An intersection type combines multiple export-list module types, forming a refined 
export-list module type. The term “intersection” can be confusing because if you 
focus on the components, it looks like an intersection type takes their union. Inter- 
section is happening to the inhabitants; a module inhabits the intersection type if 
and only if it inhabits all of the intersected module types. 

An intersection type is well formed if all of its constituent module types are well 
formed. The constituent module types need not be compatible; the intersection of 
incompatible module types is well formed but uninhabited. 

Intersection types are most often used to intersect a named module type with 
an exports module type that reveals the identity of an abstract type. For example, 
an intersection type is used to seal the IntArray module: 
541b. (predefined Molecule types, functions, and modules 529a) += <1540a 543a> 

(module [IntArray : (allof ARRAY (exports [type elem Int.t]))] 
(@m Array Int)) 


Module values and evaluation 


Every module has a run-time representation as a value. An exporting module is 
represented as a record with named fields: one field for each value component and 
each module component. Type components are used only for type checking and 
are not present at run time. A generic module is represented as a function from 
modules to modules. 

When a module definition form is evaluated, it produces a record containing the 
value and module components. When a qualified name (with a dot) is evaluated, 


14 function type with these kinds of references is called a dependent function type; in type theory, it is 
often written with a II symbol, as in IIx:7 . 7’, where r’ may mention z. 
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+ < = negated 
= 1- 

<= print 

>=  println 


Figure 9.7: Names that are overloaded in Molecule’s initial basis 


it selects a named component from a module record. When a generic-module 
definition form is evaluated, it produces a function whose arguments are module 
records and whose result is a module record. When a generic module is instanti- 
ated, the function is applied. 


A pitfall 


In Molecule, the function that a generic module evaluates to can be impure. For ex- 
ample, if a generic module includes mutable state—say it mutates a private variable 
defined with val—each instance gets fresh mutable state, which isn’t shared with 
other instances. This behavior might cause confusing results, especially if a ge- 
neric module is instantiated by the type checker during the resolution of an over- 
loaded operator. So don’t mutate variables that are defined inside generic modules. 


Syntactic sugar for records 


By analogy with uScheme’s record definition, Molecule provides syntactic sugar 
for modules that behave as records do. A record module is specified by naming 
the type of the record and listing the names and types of its fields. The module 
exports a getter function and a setter function for each field, plus a constructor 
function called make. A record module’s type can also be written using syntactic 
sugar. For example, the module type 


C(exports-record-ops t ([n : Int.t] [b : Bool.t])) 
expands to 


(exports [abstype t] 
[make : (Int.t Bool.t -> t)] 
[n : (t -> Int.t)] 
[b : (t -> Bool.t)] 
[set-n! : (t Int.t -> Unit.t)] 
[set-b! : (t Bool.t -> Unit.t)]) 


A module with this type can be defined using record-module: 


542. (transcript 530b) += <1530d 543b> 
-> (record-module MyPair t ({n : Int.t] [b : Bool.t])) 
module MyPair : 
(exports 
[abstype t] 
[make : (Int.t Bool.t -> MyPair.t)] 
[n : (MyPair.t -> Int.t)] 
[b : (MyPair.t -> Bool.t)] 
[set-n! : (MyPair.t Int.t -> Unit.t)] 
[set-b! : (MyPair.t Bool.t -> Unit.t)]) 


9.4.3 Overloading 


When every operation needs a qualified name, code can feel bloated and tedious; 
unqualified names like +, print, and = are easier on the eyes. To enable unqual- 
ified names to be used in more contexts, Molecule allows the name of a function 
to be overloaded. An overloaded name may stand for more than one value or func- 
tion; to determine which function is meant, Molecule looks at the type of its first 
argument. 

Overloading helps answer three questions that the designers of any statically 
typed programming language ought to address: 


1. Programmers like to use + for both integer addition and floating-point addi- 
tion. How is the language to know which is meant, when? 


2. Programmers like to use = for equality. How is equality supposed to be de- 
cided for values of different types? Especially abstract types? After all, equal- 
ity for something like association lists is not always obvious (page 132). And 
anything like check-expect has to use the right equality for each test. 


3. Interpreters and debuggers need to be able to print values. How does an 
interpreter know what to print? In some languages, printing the representa- 
tion might be good enough, but if representation is supposed to be hidden, 
perhaps a print operation shouldn't reveal it. 


Each of these questions is addressed by overloading: arithmetic, equality, and 
printing use conventional, overloaded names, and by overloading these names, 
programmers can specify how arithmetic, equality, and printing should behave. 

In Molecule, you overload a name by putting a function’s qualified name in an 
overload definition. Molecule’s initial basis overloads arithmetic, comparisons, 
and printing (Figure 9.7 on the facing page): 


543a. (predefined Molecule types, functions, and modules 529a) += <1541b 
(overload Int.+ Int.- Int.* Int./ Int.negated 
Int.= Int.!= Int.< Int.> Int.<= Int.>= 
Int.print Int.printin) 
(overload Bool.= Bool.!= Bool.print Bool.printin) 
(overload Sym.= Sym.!= Sym.print Sym.println) 
(overload Char.= Char.!= Char.print Char.printin) 


After these definitions, the unqualified form of each function name is now over- 
loaded. To see what an unqualified name might stand for, ask the interpreter: 


543b. (transcript 530b) += 1542 543c> 
“3s 
overloaded : (Char.t Char.t -> Bool.t) 

= : (Sym.t Sym.t -> Bool.t) 

= : (Bool.t Bool.t -> Bool.t) 

= : (Int.t Int.t -> Bool.t) 


Each of the types given is a type at which = can be used: 


543c. (transcript 530b) += <1543b 558b> 
-> (= 'yes 'yes) 
#t : Bool.t 
—> (= #f #f) 
#t : Bool.t 
-> (= 3 3) 
#t : Bool.t 


-> (= Char.newline Char.space) 
#f : Bool.t 
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User-defined functions can also be overloaded. For example, printing can be 
overloaded to work with user-defined complex numbers (Exercise 8): 
544a. (complex-number transcript 544a) = 544b > 

-> (overload Complex.print Complex.* Complex.+) 
-> (val i (Complex.new © 1)) 
i : Complex.t 
Arithmetic can also be overloaded: 
544b. (complex-number transcript 544a) += 1544a 
-> (+ (Complex.new 1 2) (Complex.new 3 -4)) 
4-2i : Complex.t 
=> CF doa) 
-1+0i : Complex.t 

Each use of an overloaded name is associated with a single function during type 
checking; the process is called overload resolution. In Molecule, overload resolution 
uses the simplest algorithm that I could find, which is based on CLU: an overloaded 
name may be used only as a function that is applied to one or more arguments, and 
the meaning of the overloaded name is resolved by looking at the type of the first 
argument. The formalities appear in Section 9.8.8. 

Overloading is sometimes called ad hoc polymorphism. I don’t care for this 
term; overloading resembles parametric polymorphism and other forms of poly- 
morphism a little too superficially for my taste. But the term is used in some other 
books and in some important and interesting papers. 


9.5 MOLECULE’S INITIAL BASIS 


Interesting abstract types require the tools needed to define interesting represen- 
tations. In addition to algebraic data types and record modules, Molecule provides 
our customary primitive representations, plus several array modules. 

Primitive types are defined in modules Int, Bool, Unit, and Sym. Their main 
types are abbreviated int, bool, unit, and sym. They are supplemented by prede- 
fined functions and, or, not, and mod, by value constructors #t, #f, and unit, and 
by the overloaded names listed in Figure 9.7 on page 542. 

Molecule includes a predefined Char module, which is not primitive; a value 
of type Char.t is represented by its Unicode code point (an integer), and module 
Char is a client of module Int. In addition to function new, which takes an integer 
designating a Unicode code point and returns the corresponding character, mod- 
ule Char exports characters left-curly, right-curly, left-round, right-round, 
left-square, right-square, newline, space, semicolon, and quote. 

To enable a compact way of implementing comparisons, Molecule includes a 
predefined module Order, whose exported type Order.t has value constructors 
LESS, EQUAL, and GREATER. 

Molecule provides several array abstractions, including ArrayList, which can 
grow and shrink at either end. All array abstractions provide constant-time access 
to elements. Arrays are supported by modules UnsafeArray, ArrayCore, Array, 
IntArray, and ArrayList. 

Predefined module types include ARRAY, GENERIC-ARRAY, and ARRAYLIST. 

Molecule also provides a generic Ref module, with operations new, !, and :=. 
References work as they do in ML. 


9.6 PROGRAM DESIGN: ABSTRACTIONS 


Because programming at scale is challenging, learning to use abstract data types 
and modules can also be challenging. But you can get started with just a few tech- 
niques: 


* When designing an interface, you must say what an abstraction is, whether 
it is mutable, what operations are supported, and what they cost. And you 
must plan for a representation that can do the job. 


Once an interface is designed, you can classify each operation as a creator, 
producer, mutator, or observer (page 111). The classification can help you con- 
firm that the interface is not missing anything obvious and that its operations 
will work well together. 


To specify the behaviors of an interface’s operations, you use the metaphor- 
ical or mathematical language of the interface’s abstractions, perhaps with 
some algebraic laws (Chapter 2). 


To relate an abstraction to its implementation, you can use two powerful 
tools: an abstraction function and a representation invariant. 


These techniques apply equally well to program design with objects (Chapter 10), 
but in this chapter they are illustrated with modules and abstract data types. De- 
scription and classification are illustrated with array lists and sets; abstraction 
functions are illustrated with multiple examples, and representation invariants are 
illustrated with priority queues, both here and in Section 9.7. 


9.6.1  Interface-design choices 


Every designer must decide whether an abstraction will be mutable, what opera- 
tions an interface will provide, and what those operations might cost. All three 
considerations influence (and are influenced by) the intended representation. 

If an abstraction has a state that can change over time, it’s mutable. Otherwise, 
it’s immutable. A mutable abstraction has a mutable representation. An immutable 
abstraction usually has an immutable representation, but it can have a mutable 
representation—a classic example is an immutable data structure with a mutable 
cache. 

Mutability isn’t arbitrary; for example, atomic values—like integers, Booleans, 
characters, and enumeration literals—are expected to be immutable. Aggregate 
values like strings, arrays, and records, which store other values inside, are of- 
ten mutable—though in functional languages, strings and records are typically im- 
mutable, while arrays typically appear in both mutable and immutable forms. 

Mutable representations normally require less allocation than immutable rep- 
resentations and so can be less expensive; for example, a mutable binary search 
tree can be updated with at most constant allocation. But a mutable representation 
demands a mutable abstraction, and compared with immutable abstractions, mu- 
table abstractions are harder to test and can lead to more bugs. In particular, when 
mutable data is shared among different parts of a program, one part can make a 
change that another wasn’t expecting. (“Not found? But that key was in the table!”) 
With immutable abstractions, these sorts of bugs can’t happen. 

General-purpose abstractions should often be designed in both mutable and im- 
mutable forms. For example, if I’m using an association list to represent an envi- 
ronment in an interpreter, I want an immutable alist—that’s going to make it easy 
to implement let expressions and closures. But if I’m using an association list to 
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implementa sparse array, I want a mutable alist—that’s going to reduce the alloca- 
tion cost of an update from linear to constant. If you design mutable and immutable 
abstractions in tandem, you'll always have the one you want when you want it. 

Abstractions can be designed in tandem in part because mutability is surpris- 
ingly independent of the designer’s other big choice: what operations to provide. 
Mutability rarely affects what operations are implemented; for example, whether 
it is mutable or immutable, a dictionary abstraction needs to implement the same 
operations: insert, lookup, update, and delete. The same is true of a stack, a pri- 
ority queue, an array, and many other abstractions. Mutability does affect costs; 
the cost of each operation, called the cost model, often depends both on mutability 
and on the representation the designer has in mind. 

Acost model determines what operations will be cheap, what operations will be 
expensive, and what operations won't be implemented at all. Identifying the right 
operations at the right cost calls for techniques from beyond the world of program- 
ming languages. But once you have a set of operations, programming-language 
techniques can help you see if it’s a good one: You can analyze the operations ac- 
cording to their classification (Chapter 2, page 111), which is closely related to clas- 
sification of rules in type theory (sidebar, page 347). 


+ Every interface needs an operation that creates a new value of abstract type: 
a creator. 


* Most interfaces need operations that can take an existing value of abstract 
type and do something with it. An operation that updates a value in place is 
a mutator; one that uses an existing value to make a new value is a producer. 
One example is insertion into a dictionary: a mutable dictionary would im- 
plement insertion as a mutator, and an immutable dictionary would imple- 
ment it as a producer. 


+ Every interface needs operations that get information out of a value of ab- 
stract type: observers. As examples, observers in my digital video recorder 
tell me whether a game has started, whether it’s over, and who’s playing. 


A classification of operations can be used to ask if a design is complete: 


* Can every part of the abstraction be observed? 
* Can every mutation be observed? 
* Can the effect of every producer be observed? 


* Can every observable be mutated (or changed by a producer)? 


A design with these properties probably meets clients’ needs—and can be tested 
without having to violate abstraction. 


9.6.2 Case study in design and specification: The array list 


Once you've chosen your abstraction and its operations, it’s time to write the com- 
plete API. The abstraction is central: it dictates the language you use to specify the 
behavior of each operation. When precision is important, the abstraction and the 
language should be mathematical, so operations can be described with mathemat- 
ical precision. As an example, I present what Java calls an ArrayList: a mutable 
sequence that provides constant-time indexing but can also grow and shrink. 

The abstraction is a sequence of elements, each of type elem. The elements are 
numbered sequentially, and the number of the first element is part of the abstrac- 
tion. I write the abstraction as (k, vs), where vs is a sequence of values and kis the 
index of the first value. 


The abstraction looks like an array, but it can grow or shrink at either end, in 
constant amortized time. I plan a single creator, operation from, which takes one 
argument k and returns (k, ||), the empty array starting at k. I don’t plan any pro- 
ducers; rather than produce a new array from an existing array, I plan to update 
arrays in place. 

Update is implemented by mutator at-put. Growth and shrinkage are imple- 
mented by mutators addlo, addhi, remlo, and remhi. Individual elements are ob- 
served by at, and the size and bounds of the array are observed by size, lo, and 
nexthi. 

547. (arraylist.mcl 547)= ($486d) 
(module-type ARRAYLIST 
(exports [abstype t] 
[abstype elem] 


[from & Cnt =2°t)] ; creator (from initial index) 
[size £.(t-=>: ant) } ; observer 
[at : (t int -> elem) ] ; observer 


[at-put : (t int elem -> unit)] ; mutator 


[lo : (t -> int)] ; observer 
[nexthi : (t -> int)] ; observer 
[addlo : (t elem -> unit)] ; mutator 
[addhi : (t elem -> unit)] ; mutator 
[remlo : (t -> elem) ] ; mutator 
[remhi : (t -> elem)])) ; mutator 


The behavior of each operation is specified mathematically, using algebraic 
laws with the abstraction (k, vs). For example, 


ee vs)) = length(vs) 
1o((k, us)) =k 
Pa e vs)) = k + length(vs) 
k)=v 
)=at 


at ( v8), 


(k, 
at((k,u:: us), k’ ((k +1, vs), k’), when k! 4 k. 


Such laws can easily specify the behavior or creators, producers, and observers. 
Specifying mutators requires more work. The best simple specification relates the 
two states of the abstraction before and after the mutation; an array A would have 
states Apre and Apos:. For example, 


* If Apre = (k, us), then after (addlo Av), Apose = (k — 1,u 2: us). 
* If Apre = (k,v :: us), then (remlo A) = v, and Apos: = (k + 1, vs). 
» After (at-put Aiv), Apost = update(Apre,t,v), where 


update((k,u:: us),k,vu’) = (k, v's: us) 
update((k,u :: us), k’,v’) = (k, vs’), 
where k 4 k’ and update((k + 1, vs), k’,v’) = (k +1, vs"). 


This design is complete: Index k can be observed using 1o, and all of vs can be 
observed by using at with an index 7 in the range lo < 2 < nexthi. Every at-put 
can be observed by an at. Effects of addlo and remlo can be observed by lo, size, 
and at. Similarly for addhi and remhi. 

The design is implemented in the Supplement, as module ArrayList. 
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Abstraction Operations 


Set At least empty/new, insert, delete, member?; pos- 
sibly also empty?, size, union, inter, diff 


Representation Invariant 

Array No element is repeated. 

List No element is repeated. 

Sorted list No element is repeated; elements are sorted. 
Binary search tree No element is repeated; smaller elements are in 


left subtrees; larger elements are in right subtrees; 
perhaps some sort of balance invariant. 


Abstraction functions 


The abstraction function combines all elements of the representation. A function 
for a binary search tree is specified in the text on the facing page; for a list, the laws 
of the abstraction function are A('()) = { } and A(cons v vs) = {v} U A(vus). 


Figure 9.8: Possible representations of a set 


9.6.3 Case study in specification using only algebraic laws: An immutable set 


Operations can be specified precisely without attributing any mathematical struc- 
ture to their abstraction: only the result of observing the abstraction is specified. 
If the abstraction is immutable, it’s enough to specify the result of each observer 
applied to the result of each creator or producer, as in Section 2.5. As an example, 
I present an abstraction of an immutable set, each element of which has type elem: 
548. (set.mcl 548) = 
(module-type SET 
(exports [abstype t] 77. a set 
[abstype elem] ;; an element of the set 


[empty : t] ; creator 
[empty? : (t -> bool)] ; observer 
[delete : (elem t -> t)] ; producer 
[insert : (elem t -> t)] ; producer 


[member? : (elem t -> bool)])) ; observer 


The interface is completely specified by these laws: 


(member? v empty) = #f 
(member? v (insertus)) =#t 
(member? v’ (insert v s)) = (member? vu’ s), where v 4 v' 


(empty? empty) = #t 

(empty? (insert v s)) = #f 

(delete v empty) = empty 

(delete v (insertus)) = (deletevs) 

(delete v (insert v’s)) = (insert vu’ (delete v s)), where v 4 v’ 


Observers member? and empty? are applied to sets made with empty and insert. Re- 
sults from delete are specified by rewriting delete away: by applying the delete 
laws repeatedly from left to right, every set made using delete is eventually shown 
to be equal to a set made with only empty and insert. 

These algebraic laws are so simple that I feel no need to specify the operations 
informally. Try writing such laws for yourself (Exercise 15)! 


Abstraction Operations 


Dictionary At least empty/new, insert/bind, delete, Lookup 
or find; possibly also empty?, size, and others 

Representation Invariant 

Association list Every key is paired with the value it maps to. 

Hash table Every key-value pair is stored in a bucket in an ar- 


ray, the index of which is a function of the array’s 
size and the element's integer hash. 


Binary search tree Pairs with smaller keys are in left subtrees; pairs 
with larger keys are in right subtrees. 


Abstraction functions 


To specify an abstraction function, treat the dictionary abstraction as an environ- 
ment (a set of key-value pairs), and use the + operation defined on page 149. For 
example, the abstraction function for an association list is defined by these laws: 


ACO) = 
A((cons (pair kv) ps)) = A(ps) + {k # v} 


Figure 9.9: Possible representations of a dictionary 


9.6.4 Representations, abstraction functions, and invariants: Getting code right 


Interface design is followed by implementation. The key choice is the represen- 
tation of each abstract type; just as an abstraction dictates the language you use 
to write the API, a representation dictates the code that you use to implement 
the module. 

A representation is chosen based on the abstraction the designer is trying to 
implement, its mutability, and the expected cost model. To choose well requires 
an understanding of data structures. Depending on circumstances, even a simple 
abstraction like a set might be represented as an array, a list, a sorted list, a move- 
to-front list, a binary search tree, a red-black tree, an AVL tree, or a hash table. 
If the set’s elements have a suitable structure, it might also be represented by a trie, 
a Patricia tree, or a bit vector. 

In this book, I can’t help you choose a data structure—or any other representa- 
tion. But once you have a representation in mind, I can show you how to get code 
right. To start, since your code operates on values of the representation, you had 
better know what those values represent. That’s the job of an abstraction function. 
Given any acceptable value of the representation type, the abstraction function says 
what abstraction the value stands for. For example, if your abstraction is a set and 
your representation is a binary search tree, your abstraction function might say 
that “a tree represents the set that contains all the elements stored at the nodes.” 

When code has to be right, its abstraction function should be written precisely— 
likely using algebraic laws. (Because an abstraction is just an idea, many abstrac- 
tion functions can’t easily be written as code.) As an example, suppose a set is 
represented as a binary search tree. A binary tree is either Empty or is (Node l vr), 
where v is a value and / and r are binary trees. The abstraction function A can be 
written with just two laws: 


A(Empty) = {}, 
A(Nodelur) = A(l) UA(r)U {v}. 
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Abstraction Operations 


Priority queue At least empty/new, insert, empty?, and 
delete-min; possibly also size, find-min, merge 


Representation Invariant 

List List is sorted with the smallest element at the front 
(inefficient unless small). 

Array Element at index 7 is not larger than the elements 
at indices 27 and 22 + 1, if any. 

Binary tree Element at node is not larger than elements at left 
and right child, if any. 

Leftist heap Binary tree, with the additional invariant that ev- 
ery left subtree is at least as high as the corre- 
sponding right subtree. 

Abstraction functions 


The abstraction function for a priority queue has the same structure as the abstrac- 
tion function for a set. For example, the abstraction function for a leftist heap says 


AcEmpty) = (Sand A(Nodelur) = A(I)UA(r) Us. 


Figure 9.10: Possible representations of a priority queue 


For a simple implementation like a linked list, an abstraction function may be 
all you need. But many implementations work correctly only with well-behaved 
representations. For example, a binary search tree works only when values in the 
left tree are smaller than the value at the root, and similarly for the right subtree. 
This property, which is usually called the “order invariant,” is an example of a repre- 
sentation invariant. The order invariant guarantees that member? can find an object, 
if present, without having to look at every node of the tree. 

Interesting data structures often satisfy multiple representation invariants. 
These may be referred to individually, and they may also be collectively called 
“the invariant.” For example, a sophisticated binary search tree also has a bal- 
ance invariant. Balance invariants come in many forms, but they all guarantee that 
member? takes time at most logarithmic in the size of the tree. 

Example abstraction functions and representation invariants for sets, dictio- 
naries, priority queues, and complex numbers are sketched in Figures 9.8 to 9.12. 
Each figure presents an abstraction, some reasonable operations, some suggested 
representations, the invariants of each representation, and something about an ab- 
straction function. 

A set (Figure 9.8) is defined by the elements it contains. 

A dictionary (Figure 9.9), which is also called a “table,” “associative array,” “en- 
vironment,” or “finite map,” is defined by a mapping from keys to values. 

A priority queue (Figure 9.10) is a “bag” or “multiset” of values. (For another 
view, see Exercise 10.) A bag is notated just like a set—elements are separated by 
commas and wrapped in brackets—but where set brackets look like {---}, bag 
brackets look like (---5. A priority queue provides fast insertion and fast access 
to the smallest value in the bag. The best representation depends on what other 
operations you want to perform at what costs. If you're willing to mutate, an array 
is very effective (Section 9.6.5). If you want an efficient merge operation, I recom- 
mend an immutable priority queue represented as a leftist heap (Section 9.7.1). 


Abstraction Operations 


2D point Constructor, vector addition, distance from ori- 
gin, scaling by a number, translation, rotation, ... 


Representation Invariant 


Cartesian coordinates (x,y) | None 


Polar coordinates (1, @) r > 0, possibly -—7 <0 <7 
Quadrant-magnitude |x| > 0, |y| >0,0<Q<4 
(Q, lal, ly) 

Abstraction functions 


For the Cartesian representation, the abstraction function is the identity function. 
For the polar representation, it is A(r,@) = (rcos6,rsin@). 


Figure 9.11: Possible representations of a point in two dimensions 


Abstraction Operations 
Complex number Constructor, +, -, *, /, negated 
Representation Invariant 


Cartesian coordinates (x,y) | None 
Polar coordinates (1, 0) r > 0, possibly -—t7 <0 <7 


Figure 9.12: Possible representations of a complex number 


A two-dimensional point on the plane (Figure 9.11) is defined by its x and y 
coordinates. If all you have is integers, Cartesian coordinates are the only game 
in town—though Exercise 6 invites you to play with a representation that stores a 
point’s quadrant and the magnitudes of the x and y coordinates. But if you have 
floating-point numbers, and if you plan lots of rotations or magnitude tests, polar 
coordinates could be a good choice. 

A complex number (Figure 9.12) is defined by its real and imaginary parts. The 
set of all complex numbers is isomorphic to the set of all two-dimensional points, 
but their operations are different. For example, two complex numbers can be 
multiplied to form a third complex number, which is not true of two-dimensional 
points. 


9.6.5 Case study: Using invariants to code a priority queue 


To demonstrate representation invariants at work, I implement a priority queue. 
The abstraction is a bag of elements, and I implement a mutable version, as de- 
scribed by this interface: 
551. (pg.mcl 551) = 552a> 
(module-type MUTABLE-PQ 
(exports [abstype t] 
[abstype elem] 


[new : ( -> t)] ; creator 
[insert : (elem t -> unit)] ; mutator 
[empty? : (t -> bool)] ; observer 


[delete-min : (t -> elem)])) ; mutator *and* observer 


Calling insert or delete-min mutates the queue that is passed in, and calling new 
creates a fresh, empty queue that is distinct from all other queues. Both insert 
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and delete-min run in time logarithmic in the size of the queue, and the other 
operations run in constant time. 

My implementation is generic: it works with any type of element, provided 
only that the smaller of any two elements can be identified. My generic module 
ArrayHeap therefore takes one argument, module Elem, which exports type Elem.t 
and function Elem. <=. Function Elem. <= must behave like a total order: it must be 
reflexive, transitive, and antisymmetric. To use ArrayHeap with any other <= func- 
tion is an unchecked run-time error. 
552a. (pq.mcl 551) += 1551 

(generic-module 
[ArrayHeap : ([Elem : (exports [abstype t] 
[<= : (t t -> bool)])] --m-> 
(allof MUTABLE-PQ 
(exports [type elem Elem.t])))] 
(representation of a priority queue 552b) 
(definitions of operations on priority queues 553a) 
) 
The result type of generic module ArrayHeap uses allof in the same way as 
IntArray (chunk 541b), for the same reason: it needs to let client code know that 
in any instance of ArrayHeap, type elem is the same as type Elem.t. 

My implementation uses the classic representation of a mutable heap: an array. 
552b. (representation of a priority queue 552b)= (552a) 

(module EA (@m ArrayList Elem)) ; EA stands for "element array" 

(type t EA.t) 

(type elem Elem.t) 
The array represents a complete binary tree in which the root is stored at index 1 
and the two children of the node at index 7 are the nodes at indices 2-7 and 2-7+ 1. 
My array A is actually the “array list” whose interface is described in Section 9.6.2, 
so in addition to its elements, it has integers lo and nexthi, which mark the ex- 
treme indices of the array. A representation A represents the bag containing all 


the elements of A: 
A(A) = (A[i] | 1 <i < nezthiS,. 


A good representation satisfies these invariants: 
Vi: lo<i< nexthi : if 2-1 < nezthi then A[i] < 
Vi: lo<i< neathi :if2-i+1 < nexthi then Ali] < 


Ss 

I 

= 
—— 


These invariants say that the value of every node is no greater than the values of its 
children, if any. 

In the invariants, the universal quantifier V2 applies to all nodes. The invariant 
can be simplified by writing the quantifier in a way that applies to all children: each 
child must be at least as great as its parent: 


lo=1 Vi: 2<i < neathi: Alidiv 2] < Ali]. 


These invariants help me guarantee that both insert and delete-min execute in 
time proportional to the logarithm of the number of elements in A. 

To ensure that the invariants hold, I use the classic method of rely-guarantee 
reasoning: 


« At the start of every operation, my code relies on every value of abstract type 
having a representation that satisfies the invariants. 


+ At the end of every operation, my code guarantees that the representation of 
every value of abstract type satisfies the invariants. 


If your invariants keep airplanes from falling out of the sky or keep nuclear 
power plants from venting radioactive gas, you prove that they hold, using program 
verification. But program-verification techniques are beyond the scope of this book. 
A “cheap and cheerful” alternative is to check invariants at run time. (Dynamic 
checking is cheap only in programming effort; it can be expensive in run-time cost.) 
In Molecule, dynamic checking uses an assert form. Assertions can invalidate an 
interface’s cost model, do not actually prove anything, and do not even catch all 
invariant violations. But assertions do catch some bugs, which can be a fine thing. 

To use the invariant in an assertion, I need to express it in code. I use the ver- 
sion that quantifies over children, and to check a single child, I define an auxiliary 
function good-child?, to which I pass 2-2or2-72+4 1. 
553a. (definitions of operations on priority queues 553a) = (552a) 553b> 

(define bool good-child? ([a : t] [child-index : int]) 
(let ([parent-index (/ child-index 2)]) 
(Elem.<= (EA.at a parent-index) (EA.at a child-index)))) 


The invariant is satisfied if Jo = 1 and all children are good. To test it, I define 
higher-order function all-in-range?, which tests all integers in a given range. 
553b. (definitions of operations on priority queues 553a) += (552a) <1553a 553c> 
(define bool all-in-range? ([i : int] [limit : int] [p? : (int -> bool)]) 
;; true iff for every k such that i <= k < limit, k satisfies p? 
CI (= i limit) 
(&& (p? i) (all-in-range? (+ i 1) limit p?)))) 


(define bool invariant? ([a : t]) 
(&& (= (EA.1lo a) 1) 
(all-in-range? 2 (EA.nexthi a) (lambda ([i : int]) (good-child? a i))))) 

Using function invariant?, I define a validator for representations. An invalid 
representation triggers an assertion failure. 
553c. (definitions of operations on priority queues 553a) += (552a) <553b 553d> 

(define t validate ([a : t]) 
(assert (invariant? a)) 
a) 

The invariant is exploited for both insertion and deletion, and insertion is a lit- 
tle easier to understand. Function insert adds a new element at the high end of 
the array, in position n. Now every position 7 satisfies the invariant, except possi- 
bly position n. If A[n div 2] < A[n], then position n satisfies the invariant. Oth- 
erwise insert swaps A[n] with A[n div 2], then tries again with a new value of n. 
Eventually either A[n div 2] < A[n] or else n = 1, and either way the invariant is 
eventually satisfied. 
553d. (definitions of operations on priority queues 553a) += (552a) <1553c 554a> 

(define unit insert ([v : Elem.t] [q : t]) 
(let ([n (EA.nexthi (validate q))]) 

(EA.addhi q v) 

; loop invariant: (EA.at qn) == v 

(while (&& (> n 1) (not (Elem.<= (EA.at q (/ n 2)) v))) 
(EA.at-put q n (EA.at q (/ n 2))) 
(EA.at-put q (/ n 2) v) 
(set n (/ n 2))) 

(assert (invariant? q)))) 

Deletion is a little more complicated. The invariant ensures that the smallest 
elementis always stored in A[1], so function delete-min removes A[1], then moves 
in the last element of A, if any. At that point the invariant could be violated in this 
way: A[1] could be larger than its children, A[2] and A[3]. To restore the invariant, 
delete-min swaps A[1] with the smaller of A[2] and A[3]. Now A[1] satisfies the 
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invariant, but the child that was swapped may not. That child is at index 2 or 3, but 
the computation generalizes to A[i], A[2-i], and A[2-7+ 1]. Function delete-min 
keeps swapping, and 72 keeps growing, and this computation continues until either 
the relations are satisfied or A[#] has no children. 


554a. (definitions of operations on priority queues 553a) += (552a) 553d 554d> 
(definition of internal operation swap 554c) 
(define Elem.t delete-min ([a : t]) 
(let* ([a (validate a)] 
[min (EA.at a 1)] ; to be returned 
[v (EA.remhi a)]) ; to move into position 1 
(when (> (EA.size a) 0) 
(let* ([{i 1] 
[_ (EA.at-put ai v)] 
[left-index (* i 2)] 
[right-index (+ 1 left-index) ] 
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[limit (EA.nexthi a)] 
[in-array? (lambda ([j : int]) (< j limit))] 
[bad? (lambda ([j : int]) 
(&& (in-array? j) (not (good-child? a j))))]) 
; loop invariant: left-index == 2 * i 
: right-index ==2 *i+1 


(while (|| (bad? left-index) (bad? right-index) ) 
(swap A[i] with the smaller of A[right-index] and A[left-index] 554b) ))) 
(assert (invariant? a)) 
min)) 
The swap is a little more complicated than I make it sound. If right-index is 
beyond the bounds of A, the only choice is to swap with the left child. 
554b. (swap Ali] with the smaller of A[right-index] and A[left-index] 554b)= (554a) 
(let* ([hasn't-right (>= right-index (EA.nexthi a))] 
[to-swap (if hasn't-right 


left-index 
(if (Elem.<= (EA.at a left-index) (EA.at a right-index)) 
left-index 


right-index))]) 
(swap a i to-swap) 
(set i to-swap) 
(set left-index (* 2 i)) 
(set right-index (+ left-index 1))) 


The swap function uses a let expression: 


554c. (definition of internal operation swap 554c)= (554a) 
(define unit swap ([a : t] [i : int] [j : int]) 
(let ([x (EA.at a i)] 
[y (EA.at a j)]) 
(EA.at-put ai y) 
(EA.at-put a j x))) 


To wrap up, a priority queue is empty if its representation has no elements. 


554d. (definitions of operations on priority queues 553a) += (552a) <1554a 554e> 
(define bool empty? ([q : t]) 
(= 0 (EA.size (validate q)))) 


And a new priority queue is empty and satisfies Jo = 1. 


554e. (definitions of operations on priority queues 553a) += (552a) «554d 
(define t new () 
(validate (EA.from 1))) 


The priority queue can be used, among other things, for sorting (Exercise 40). 


9.7 KEY FEATURE: INSPECTING MULTIPLE REPRESENTATIONS 


As noted at the beginning of this chapter, a programming language may support 
data abstraction through one or both of two mechanisms: abstract data types or 
objects. Both mechanisms work equally well with the design techniques in the pre- 
vious section, but they aren't equally good at everything. Each mechanism can do 
things that the other cannot, and one of the most important differences is illus- 
trated in this section: A function defined in a module can see the representations 
of all its arguments of any abstract type defined in that module; a method defined 
on an object can see only the representation of that object, not the representations 
of other objects of the same class. (Objects’ limitations are also a strength: because 
a method sees only the representation of its own object, it can easily interoperate 
with other objects of different classes. This is a benefit that can’t be achieved using 
abstract data types—see Section 10.8.) To show the power of being able to see rep- 
resentations of multiple arguments, I present an example using priority queues; 
examples involving arbitrary-precision arithmetic and sets of integers are left as 
exercises. 


9.7.1 Priority queues optimized for merging: Leftist heaps 


The priority queue in the previous section—a complete binary tree represented by 
an array—provides insertion and removal in O(log N) time, but it does not provide 
a merge operation. To merge two priority queues you would have to remove all 
the elements from one and add them to the other, which would cost O(N log N). 
In this section, I present an immutable priority-queue abstraction with an efficient 
merge operation: the leftist heap. The merge operation can be implemented effi- 
ciently only because it can inspect the representation of both heaps. 
Animmutable priority queue exports roughly the same operations as a mutable 
priority queue, but the operations have different types: 
555a. (leftist.mcl 555a)= 555bD 
(module-type IMMUTABLE-PQ 
[exports [abstype elem] 
[abstype t] 


[empty 6 oe] ; creator 
[insert : (elem t -> t)] ; producer 
[merge : (t t -> t)] ; producer 
[Lempty? : (t -> bool)] ; observer 


[module [Pair : (exports-record-ops pair 
({min : elem] [others : t]))]] 
[delete-min : (t -> Pair.pair)]]) ; observer/producer 


Operation delete-min returns a pair holding min, the smallest element, and the 
others; the pair type is defined internally in nested module Pair. 
Module Leftist uses allof in the same way as IntArray and ArrayHeap. 


555b. (leftist.mcl 555a) += <1555a 

(generic-module 

[Leftist : ([Elem : (exports [abstype t] 

[<= : (t t -> bool)])] --m-> 
(allof IMMUTABLE-PQ 
(exports [type elem Elem.t])))] 

(representation of a priority queue as a leftist heap 556a) 

(definitions of operations on leftist heaps 556b) 
) 


The representation and operations are shown on the next couple of pages. 
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A leftist heap is a binary tree in which every node satisfies two invariants: 


* The heap invariant says that the value stored at the node is no greater than 
any value stored in either of its subtrees. 


* The path-length invariant says that if path lengths are measured from the 
node to the leaves, the shortest path is on the right. 


The path-length invariant needs to be made precise, but the imprecise version ex- 
plains why the representation is called “leftist”: longer paths are on the left, so the 
left subtree tends to have more nodes. 

To make the path-length invariant precise, I define the rank of a tree as the 
length of the shortest path from the root to a leaf. Rank is defined inductively: 
the empty tree has rank zero, and a nonempty tree has rank one more than the 
minimum rank of both subtrees. The path-length invariant says that in any non- 
empty node of a leftist representation, the rank of the left subtree is at least as great 
as the rank of the right subtree. To maintain the invariant, when I make a new node 
I put the higher-rank subtree on the left. 

Rank can be computed by visiting every node, but that’s costly. Instead, each 
node’s rank is cached in the node itself, making the rank available in constant time. 
Because the representation is immutable, rank needs to be computed only once, 
when the node is built—afterward, the cached rank is always up to date. The binary 
tree is represented using an algebraic data type; rank is cached only in a nonempty 
tree. 
556a. (representation of a priority queue as a leftist heap 556a)= (555b) 

(type elem Elem.t) 
(data t 
[LEAF : t] 
[NODE : (Elem.t t t int -> t)]) ; value, left and right subheaps, rank 
Thanks to the cache, the rank of any tree is available in constant time: 
556b. (definitions of operations on leftist heaps 556b) = (555b) 556c > 
(define int rank ([heap : t]) 
(case heap 
[LEAF 0] 
[(NODE _ _ _ n) n])) 


A new node is built by unexported operation make-node-heap, which takes an 
element x and two subheaps h1 and h2. The function uses ranks to maintain the 
path-length invariant of the data structure: it puts the higher-rank subheap on the 
left. The caller must ensure that x is no greater than any element of h1 or h2. 
556c. (definitions of operations on leftist heaps 556b) += (555b) <556b 557> 

(define t make-node-heap ([x : Elem.t] [h1 : t] [he : t]) 
77 return a node containing the given element and subheaps 
(let* (Lrank1 (rank h1)] 
[ranke (rank h2)]) 
(if (> rank1 ranke2) 
(NODE x hi h2 (+ 1 ranke)) 
(NODE x he hi (+ 1 rank1))))) 

Function make-node-heap is used in the efficient merge operation. Function 
merge takes two arguments and so must handle four cases, but three of those cases 
are uninteresting: when an empty heap LEAF is merged with any other heap h, the 
result is just h. When two nonempty NODE heaps are merged, the smaller of the two 
root values is chosen to be the root value of the new heap, and from among its left 
and right subheaps, plus the heap not chosen, merge has to make two subtrees for 
the new node. Because the left subheap of the chosen heap has higher rank, it is 
left alone, and the right subheap is merged with the not-chosen heap. Using the 


lower-rank subheap in the recursive merge guarantees good performance. 


557. (definitions of operations on leftist heaps 556b) += (555b) <556c 
(define t merge ([h1i : t] [he : t]) 
(case hi 
[LEAF he] 
CCNODE x1 left1 right1 rank1) 
(case h2 
[LEAF h1] 


[CNODE x2 left2 right2 rank2) 
(if (Elem.<= x1 x2) 
(make-node-heap x1 left1 (merge right1 h2)) 
(make-node-heap x2 left2 (merge right2 h1)))])])) 
This optimized merge is possible only because merge can inspect the representa- 
tions of both arguments, h1 and h2. 
The other operations are left to you (Exercise 33). 


9.7.2 In-depth case study: Arithmetic 


To get experience writing functions that can inspect all of their arguments, try im- 
plementing arithmetic. A function that adds two numbers, for example, needs ac- 
cess to every digit of both numbers. By implementing arithmetic on so-called large 
integers, where there is no a priori limit to the number of digits, you can compare the 
abstract-type approach to data abstraction (this chapter) with the object-oriented 
approach (Chapter 10). Arithmetic was once every schoolchild’s introduction to al- 
gorithms, but if you have forgotten the classic algorithms used to add, subtract, and 
multiply numbers of many digits, they are explained in detail in Appendix B. 

Implementing arithmetic will give you insight into similarities and differences 
between abstract data types and objects. Abstract data types and objects use the 
same representation (“sequence of digits”), and they use data abstraction to protect 
the same invariants (“the leading digit of a nonzero number is never zero”), but 
from there, they diverge: 


* In Exercise 49 in this chapter, you can define a function that adds two natural 
numbers. Because it is defined in the same module as the representation of 
natural numbers, this function can simply look at the digits of both represen- 
tations, add them pairwise, and return a result. But this function is limited 
to the type on which it is defined; it cannot dream of, for example, adding a 
natural number to a machine integer to get a natural-number result. If client 
code wants to add a natural number and a machine integer, it must first co- 
erce the machine integer to a natural number. (Such a coercion is a key step 
in the algorithm for multiplying two natural numbers.) 


* By contrast, an addition method defined on an object can see only the digits 
of the addend on which it is defined; it must treat the other addend as an ab- 
straction. To make addition possible requires changing the abstraction’s API, 
so it can include operations like “tell me your least-significant digit.” But be- 
cause the other addend is an abstraction, it doesn’t have to have the same rep- 
resentation as the first addend—and in Exercises 37 to 39 in Chapter 10, you 
can build an object-oriented implementation of arithmetic that can seam- 
lessly add machine integers and large integers. Using objects, client code 
can simply add numbers and not worry about their types. 


Large integers make a great case study for comparing abstract data types with ob- 
jects, but they are also a vital abstraction in their own right—integers of practically 
unlimited size are supported natively in many programming languages, including 
Icon, Haskell, Python, and full Scheme. 
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9.8 MOLECULE’S TYPE SYSTEM: ENFORCING ABSTRACTION 


Access to information about abstract types is controlled by a type system. Mole- 
cule’s type system supports data abstraction with abstract types and modules, in- 
cluding generic modules and nested modules, in much the same way as other lan- 
guages that provide these features. Molecule’s type system also supports function 
overloading, but Molecule’s overloading is just a convenience, not a good model of 
overloading as it is found elsewhere. Regardless, Molecule’s type system is more 
ambitious than the type systems in Chapters 6 to 8. What the type system does 
and how it works are explained in this section. The section begins informally, goes 
deep into formal details, and concludes with some comparisons. 


9.8.1 What the type system does and how 


The type system’s main job is to make modules and abstract types work: 


+ When a module is sealed, the type system hides the representations of its 
abstract types, and it gives each abstract type a new identity. 


* When a module is copied or is passed as a parameter to instantiate a generic 
module, the type system preserves the identities of its abstract types. 


* When a module type is ascribed to a module, whether by sealing or by in- 
stantiation, the type system ensures that the module implements the module 
type ascribed to it. 


* When a generic module is defined, the type system checks it right away, as- 
suming that each parameter has the module type claimed for it. When the 
module is instantiated, the type system checks that each actual parameter 
implements the corresponding module type, but it needn't check the generic 
code again—if the actual parameters are OK, the instance is guaranteed to be 
well typed. This ability to check a generic module once, rather than have to 
check each instance, is an example of modular type checking. 


Each aspect of the job is illustrated below with an example. 

As an example of sealing, module Char is sealed with a signature that declares 
[abstype t]. Inside Char, type Char.t is defined as type int, and the values ex- 
ported from module Char are just integers: 


558a. (definitions inside module Char 558a)= (S484b) 
(type t int) 
(val space 32) 


(val right-curly 125) 


Although type Char .t is defined as int, this identity is known only inside the Char 
module. On the outside, type Char.t has a new identity that is distinct from int, 
and it is known only by that identity. So a value of type Char.t won’t work with 
integer operations: 
558b. (transcript 530b) += <1543c 559a> 
-> (+ 1 Char.right-curly) 
type error: function + expects second argument of type Int.t, but got Char.t 
-> (= 125 Char.right-curly) 
type error: function = expects second argument of type Int.t, but got Char.t 


Char. right-curly does not work with operations exported from Int; it works only 
with the operations exported from Char (print and print1n). 


As an example of identity preservation, I copy module Char into module C. Be- 
cause copying the module doesn’t change its types, type C.t is the same type as 
Char.t. And the right-curly value from module Char does work with the print1n 
operation from module C: 
559a. (transcript 530b) += <1558b 559b> 

-> (module C Char) 
-> (C.printin Char.right-curly) 


3 
unit : Unit.t 


The identity of type Char.t is preserved by a transformation called strengthening: 
when Char is used on the right-hand side, all uses of its abstract type t are replaced 
with the fully qualified name Char.t. In addition, the module type is changed so 
that type t is no longer abstract; instead, t is made manifestly equal to itself: 
559b. (transcript 530b) += 1559a 559 > 
-> (module C Char) 
module C : 
(exports 
[type t Char.t] 
[new : (Int.t -> Char.t)] 


Both representation hiding and identity preservation rely on a single mecha- 
nism: each abstract type is identified with a fully qualified name, which is called 
its absolute access path. The absolute access path is the path you would use at top 
level to refer to the type; such a path begins with the name of a module or with 
an instance of a generic module. As examples, the type “integer” is identified with 
absolute access path Int.t, and the type of “array of Booleans” is identified with 
the absolute access path (@m Array Bool).t. 

Every absolute access path begins with a root, which identifies the top-level def- 
inition in which the path is located. A root is one of the following: 


+ An exporting module defined at top level 
+ A formal parameter to a generic module 
+ A definition of a module type (the special “placeholder” root e) 
* The result type of a generic-module type (another placeholder) 


A new, unique root is created for every new module, regardless of what the module 
is named—that is, module-definition forms are generative (Sections 8.5 and 9.8.9). 
Because every root is unique, or has a unique root substituted for it when used, 
every absolute access path is also unique. 

Giving every type a unique absolute access path is the key to the type sys- 
tem: in Molecule, two types are equal if and only if they are identified with the same 
path (or if they are function types mapping equal argument types to equal result 
types). Type equality is used to ensure that each component of a module meets 
its specification—that is, if a module type includes a value component, the module 
must define that component, and the component must have the expected type. 

When sealed, an entire module is also checked to see if it meets its specification. 
For example, module IntArray cannot be sealed with a module type that specifies 
“array of Booleans”: 
559¢. (transcript 530b) += <1559b 560aD 

-> (module-type BOOLARRAY (allof ARRAY (exports [type elem Bool.t]))) 

-> (module [MyArray : BOOLARRAY] IntArray) 

type error: interface calls for type elem to manifestly equal Bool.t, 
but it is Int.t 
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Because IntArray does not implement BOOLARRAY—the element type is wrong—this 
sealing doesn’t typecheck. But sealing IntArray with a module type that specifies 
“array of integers” is just fine: 


560a. (transcript 530b) += <1559c 560b> 
-> (module-type INTARRAY (allof ARRAY (exports [type elem Int.t]))) 
-> (module [MyArray : INTARRAY] IntArray) 
module MyArray : 
(exports 

[abstype t] 

[type elem Int.t] 

[new : (Int.t Int.t -> MyArray.t)] 

[empty : ( -> MyArray.t)] 

[size : (MyArray.t -> Int.t)] 

[at : (MyArray.t Int.t -> Int.t)] 

[at-put : (MyArray.t Int.t Int.t -> Unit.t)]) 


The type system checks that IntArray implements INTARRAY, and this sealing is 
accepted. 
As another example, even though an integer heap made with ArrayHeap has an 

array representation, it cannot be sealed with an ARRAY specification: 
560b. (transcript 530b) += <1560a 560c> 

-> (module [IntHeap : ARRAY] (@m ArrayHeap Int)) 

type error: interface calls for value new to have type ... 

but it has type (-> (@m ArrayHeap Int).t) 


The check fails because the integer heap’s new operation has a type that is different 
from what the ARRAY interface specifies. The types of all the operations can be seen 
by giving the instance a name (IntHeap) without any sealing: 


560c. (transcript 530b) += <1560b 560d> 
-> (module IntHeap (@m ArrayHeap Int)) 
module IntHeap : 
(exports 
[type t (@m ArrayHeap Int).t] 
[type elem Int.t] 
[new : ( -> (@m ArrayHeap Int).t)] 
[insert : (Int.t (@m ArrayHeap Int).t -> Unit.t)] 
[empty? : ((@m ArrayHeap Int).t -> Bool.t)] 
[delete-min : ((@m ArrayHeap Int).t -> Int.t)]) 


When a module is sealed, the type system checks that the module implements 
the interface used to seal it. And similarly, when a generic module is instantiated, 
the type system checks that each module argument implements the interface of the 
corresponding formal parameter. For example, the ArrayHeap module requires a 
formal parameter whose interface exports a type t and a <= operation. Module 
Int implements that interface, but Bool doesn’t, so ArrayHeap can’t be instantiated 
with Bool: 


560d. (transcript 530b) += <1560c 560e> 
-> (module BoolHeap (@m ArrayHeap Bool) ) 
type error: module Bool cannot be used as argument Elem to generic module ... 


To create a Boolean heap, I must define a module that implements an order 
operation on Booleans: 


560e. (transcript 530b) += <1560d 561> 
-> (module [OrderedBool : (exports [type t Bool.t] 
[<= : (Bool.t Bool.t -> Bool.t)])] 
(type t Bool.t) 
(define t <= ({[p : t] [q : t]) 
(or (not p) q))) 


Subtype and supertype: Which way? 


The directions of “subtype” and “supertype” always confuse me. I think of the 
“sub” in “subtype” and think it means “fewer,” but actually a subtype has more 
components. I correct my thinking by asking how many inhabitants a module 
type has. A subtype has fewer inhabitants—that is, there are fewer modules that 
redeem the promise made by the type. In fact the inhabitants of a subtype are 
a subset of the inhabitants of the supertype—which is why an inhabitant of the 
subtype may be used anywhere an inhabitant of the supertype is expected. 


Now module OrderedBool can be used to instantiate ArrayHeap: 
561. (transcript 530b) += <1560e 566> 
-> (module BoolHeap (@m ArrayHeap OrderedBool)) 
module BoolHeap : 
(exports 
[type t (@m ArrayHeap OrderedBool).t] 
[type elem Bool.t] 


To check whether a module implements an interface, Molecule’s type system 
uses two ideas: subtyping and principal module types. One module type is a subtype 
of another, written Tsu, <: Tsuper, if a module of type 7s.» can be used anywhere 
that a module of type Tsuper is expected. (This idea generalizes to other languages, 
including languages without modules, in which subtyping is defined only on core- 
layer types.) For modules, subtyping is determined by a module’s components: 
A subtype has to include every component called for in the supertype, and every 
component has to meet the supertype’s specification. A subtype could also include 
extra components not called for in the supertype (sidebar on the current page). 

The principal module type of a module is the one that reveals as much infor- 
mation as possible about the module’s component definitions. Each definition may 
contribute one or more declarations to the principal module type: A val or define 
definition contributes a val declaration, a type definition contributes a manifest- 
type declaration, and a module definition contributes a module declaration. A data 
definition contributes one declaration for the type and one for each value construc- 
tor, and an overload definition doesn’t contribute any declarations. 


9.8.2 Introducing the formalism 


Molecule’s type system uses techniques that should be familiar from Chapters 6 
and 8, but at a larger scale. Its elements are shown in Figure 9.13 on the following 
page, which depicts the major metavariables, the syntax, and the environment. 

The type system is organized around access paths; a path is written 7. A path 
may be a bare module name M, or it may be formed by selecting a value, type, or 
module component from a shorter path. Or a path may be an instance of a generic 
module, or finally, a path may be just e, which is a placeholder used to describe a 
module type that is not yet part of a module definition, like the module type ARRAY. 

The typing rules are written using a compact representation of syntax (Fig- 
ure 9.13e). Because the type system is so large and because declarations and com- 
ponents are so similar, the metavariable D stands not only for a declaration as 
written externally in the source code but also for a component of a module used 
internally. 
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(a) Names 


t Name of a type 

T Name of a module type 

xorf Name ofa variable (or function) 
M Name of a module 

K Name of a value constructor 


(c) Declarations: Syntax and theory 


[abstype f¢] ti xort: [*|x 
[typetT] i 
[v@:7T] a 


[module(M:7]] M:T 


(b) Syntax, environments 


7 Access path 

e Expression 

d Definition 

ds _List of definitions 

T Type 

T Module type 

D Declaration or component 

Ds List of declarations or components 
C Context of a definition 

E Static (typechecking) environment 
p Dynamic (evaluation) environment 


(d) Bindings in the typechecking environment 


Ct Name ¢ is an abbreviation for type T 

T=T Name T is an abbreviation for module type 7 

GET Variable x is defined with type r 

M:|T\e Module MM is defined at absolute path 7 with module type 7 
x €[T1,--.,7] Name x is overloaded at types 7; to Tn 


(e) Grammars for syntax, environments, paths, and contexts 


Tn) |@ 


[]|Bt=7|B,a2:7r| BM: [Pla sea | Bee S [rages ora 


x= M|ra|rt|7M | mam --- 

T ::= Exports(Ds) | Ti \ 72 | (Mi: Ti) x +++ x (Mn: Th) 2 T 
Da pae tak | eta | Mat 

C= []| nl] 

Tonsm|TX +X moO 

a 

rae 


| MODULE-TYPE(T, 7 ) 
| 


VAL (x, €) | VAL-REC(x : 7,e) | TYPE(t,7) | OVERLOAD(7) | DaTA(-- - ) 


MODULE([M : 7], ds) | MoDULE([M : T], 7) | MoDULE(M, 7) 


Figure 9.13: Metavariables, syntax, and the type-checking environment 


Figure 9.13c clarifies the meaning of the declaration forms by relating concrete 
syntax to theory notation. Each form of theory notation expresses a type-theoretic 
idea: abstract type t has kind *; manifest type t is equal to 7; and so on. As shown 
in the figure, abstract-type declarations have two theory forms: The external form 
simply identifies an abstract type t, and it is notated ¢ :: *. The internal form is 
decorated with its absolute access path 7, and it is notated ¢ :: | «|. 

To compute the absolute access path of each type and module, the type system 
tracks the context of each declaration and definition. The form of a context C' is 
shown in Figure 9.13e. A context has a hole [], which is filled in with a name, like 
the name of a defined module. Filling the hole turns the context into a path. Each 


top-level definition is elaborated in the context |], which is just a hole. The name 
used to fill it is the name of the module being defined. 

A type T is either an absolute access path or a function type. 

Abstract syntax includes lists of definitions ds and of declarations Ds. In this 
chapter, lists are written differently than in other chapters: a nonempty list is 
formed using an infix comma, which can mean not only cons but also append or 
snoc (which adds a single element to the end of a list). The comma is also used to 
pattern match on nonempty lists. This notation simplifies the typing rules. 

Compared with type systems that appear in earlier chapters, Molecule’s dif- 
fers most in its type-checking environment. Molecule’s type-checking environ- 
ment does the same work as Typed jsScheme’s [' and A environments combined: 
it tracks the type of each value and the kind of each type constructor.’ But it also 
tracks the type that each type abbreviation stands for, the module type of each 
module, the module type that each module-type abbreviation stands for, and the 
possible types of each overloaded name. This information could conceivably be 
distributed over multiple different environments, much as types and kinds are dis- 
tributed over environments I‘ and A in Typed Scheme, but putting it all into a 
single environment F simplifies the forms of many judgments. One consequence 
is that Molecule cannot simultaneously have both a value and a type of the same 
name, but this restriction is one I can live with. 

A type-checking environment F is written as a sequence of bindings. A bind- 
ing resembles a declaration, and both bindings and declarations are notated with 
metavariable D. But a binding differs from a declaration in the following ways: 


+ A type binding in an environment always contains a manifest type; no type 
is ever bound into an environment as abstract. If an abstract type is entered 
into an environment, it is entered as manifestly equal to itself. This trick is 
analogous to strengthening. 


+ When a binding associates a module’s name MV with its module type 7, the 
module type is rooted in path 7 the binding is written M/ : | 7 |,, where 7 is 
M’s absolute access path. Both type and path are needed because M can be 
used in two ways: When / is used to define another module or as an actual 
parameter to a generic module, its type 7 is needed for type checking. And 
when is used to form a path—that is, when code names a type component 
like M.t—M’s absolute path 7 is used to form path 7.t, which determines 
the identity of the type. 


- A binding of the form T’ = TJ can associate module type 7 with name T’. 
Because a module type cannot be a component, such a binding has no cor- 
responding declaration form. 


* The binding of an overloaded name, which is written x € [71,..., Tn], tracks 
all the types at which name x may be used. Such a binding has no corre- 
sponding declaration form. 


Even though an environment is written as a sequence of bindings, it still has a 
domain; dom(£) is a set of names, each of the form t, x, M, or T. An environ- 
ment F can even be applied, like a function, to a name in its domain, but Mole- 
cule’s typing rules use a different notation. The typing rules look names up using 
the relation & 5 D, pronounced “FE has D,” where D is a binding. This nota- 
tion has the advantage that it can be extended to suggest that F binds paths (Fig- 
ure 9.22, page 574), which provides a compact way to associate types with quali- 


*In Molecule, that kind is always *. 
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fied names. For example, if Ho is Molecule’s initial environment, then judgment 
Eo > Int.negated : (Int.t — Int.t) is derivable. 

An environment may bind relative paths as well as absolute ones. As an exam- 
ple, in module OrderedBool, the relative path t is bound to type Bool.t. As another 
example, in the definition of module type IMMUTABLE-PQ (chunk 555a), the relative 
path Pair.t is bound to the absolute path e.Pair.t. 

One last preliminary: To avoid dealing with too many lists, the type theory sim- 
plifies the syntax in two ways. First, the allof form is expressed using an A oper- 
ator, according to these equations: 


ALLOF(|]) = EXPORTS() 
ALLOF({7]) = 7 
ALLOF((71, 72,---, Tn]) = Ti A ALLOF([7o,.--, Jnl). 


Like an allof type, a type of the form Jj / 72 is an intersection type; the \ symbol 
can be pronounced “and also.” 

The second simplification is for overload: although the concrete syntax may 
list as many paths as you like, the type theory overloads one path at a time. 

An overview of the entire type system is shown in Figure 9.14 on the next page. 
While the figure shows a lot of judgments, only three things are really going on: 
elaboration, principal types, and subtyping. In this order, 


* Types and module types are elaborated, which replaces each type abbrevia- 
tion with its referent. Elaboration also replaces relative paths with absolute 
paths as needed. And although it is mostly glossed over, elaboration dec- 
orates the application of every overloaded function name, so the evaluator 
knows which overloaded function is meant. 


* The principal type of each module is computed. The key judgment is 
E - |d\c : Ds, which checks a definition d and produces bindings Ds. 
The bindings are added to the environment and may also become compo- 
nents of a principal module type. 


+ Ascriptions are checked using subtyping. A module type may be ascribed toa 
module in two ways: the module is sealed with a module type, in which case 
the sealing module type is ascribed to the module, or the module is used to 
instantiate a generic module, in which case the type of the formal parame- 
ter is ascribed to the module. In both cases, the module’s principal type is 
checked to be sure it is a subtype of the module type ascribed to it. 


Checking ascriptions is the ultimate goal, so we begin our study with subtyping, 
then work through principal module types and elaboration. 


9.8.3 Subtyping and intersection types 


Module type 7 is a subtype of J’ if TJ provides everything that J’ is expecting. 
The judgment is written 7 <: J’, and it is sound if every inhabitant of 7 is also an 
inhabitant of 7’. Relevant rules are shown in Figure 9.15 on page 566. 

In Molecule, only the types of exporting modules are related by subtyping.? 
The judgment form 7 <: J’ needs only two rules: one when the supertype 7’ is 
an intersection type, and one when itis a list of exported components. The rule for 


3Subtyping of intersection types or module-arrow types is relatively easy, but combining them can 
be gnarly. 


Elaboration Replaces type abbreviations with their referents; converts 
relative paths to absolute paths; resolves applications of 
overloaded names. 


Ered Type T is well formed (with kind *) and stands for r’. 

E|T|;,~T' At path 7, module type 7 is well formed and elaborates to 
T’ (elabmt). 

Et} |Ds|, ~~ Ds’ Declarations within exports elaborate. 

Et |D|,~ D’ A single declaration elaborates. 

Etrewe:r Expression e has type 7 and elaborates to e’ (which is e 
decorated with the resolution of overloaded functions). 

Bre:T Expression e is elaborated, but we ignore the elaboration 
and look only at the type T. 

Principal Types Checks that a module is well formed and computes its 
principal type. 

EF |ds|r:T7 At path 7, a module with definitions ds is well formed and 
has principal module type T. 

EF |ds|, : Ds At path 7, definitions ds are described by declarations Ds. 

EF |d|c: Ds In context C and environment F, definition d is well 
formed and adds bindings Ds to the environment. 

BbariT The module defined at path 7 has type 7. 

Subtyping Tests if a module or component meets a specification. 

Pegs Module type 7 is a subtype of module type 7’. 

D<: D' A component described by D matches the specification D’. 

Ds <: Ds' A sequence of components described by Ds matches 
specification Ds’. 

Lookup Looks up a name or a path, including instances of generic 
modules. 

E>D Environment F binds a name or path as described in 
binding D. 


Figure 9.14: Judgments of the type system 


subtypes of intersection types gets at the very idea of subtyping and intersection: 
a module inhabits type 7, \ 7; if and only if it inhabits both 7/ and 73. The rule 
for subtypes of an intersection type is therefore sound and complete. (If you like 
math, subtyping is a partial order, and the A operator finds a greatest lower bound.) 

The rule for a subtype of an export list checks that every component of the su- 
pertype is present in the subtype. The components of the subtype are calculated 
by this function: 


comps(EXPORTS(Ds)) = Ds 
comps(71 A 72) = comps(71), comps(72) 
comps((M, : 71) x «+» x (My: Tn) “9 T) = []. 


The result of applying comps to an intersection type might not be a well-formed ex- 
port list. That’s because intersected module types may have repeated components 
or may even be inconsistent. It turns out, however, that an inconsistent module 
type can be accepted by the type system without causing a problem. For example, 
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PRET OT Bs comps(7 ) <: Ds’ 


ee oat Bs 
Eee TOs T <: ExPoRTS(Ds’) 
Ds <: Ds' —— 
Ds <: {] 
pais ge Ds = D8 pre, D, D8 post pesp! APE Bd 
te 
Bails tees Ds <: (D", Ds’) 
modules 
D<: D’ 
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Pay 


till, <it=a HO ee Oe a M:T<:M:T' 
Figure 9.15: Subtyping 


a module type might be inconsistent because it claims two different identities for 
atypet: 
566. (transcript 530b) += 1561 567> 

-> (module-type INCONSISTENT 

(allof (exports [type t Bool.t]) (exports [type t Int.t]))) 
module type INCONSISTENT = 
(allof (exports [type t Bool.t]) (exports [type t Int.t])) 

Because this module type has no inhabitants, it’s harmless. In particular, be- 
cause module type INCONSISTENT is uninhabited, proving a judgment of the form 
INCONSISTENT <: 7’ causes no issues. Because INCONSISTENT has no inhabitants, 
every inhabitant of INCONSISTENT is also an inhabitant of 7’, so the judgment is 
sound. And if you try to seal a module with type INCONSISTENT, you'll find that you 
can't—although you might be frustrated by the error messages. 

Once function comps produces components, they are checked using judgment 
Ds <: Ds’. If Ds’ is empty, it is supplied by any sequence of components. If Ds’ is 
nonempty, then it has the form (D”, Ds”), which is supplied if both D” and Ds” 
are supplied. Components may be supplied in any order. 

A single supplied component is checked using judgment D <: D’. An abstract 
type may be supplied by another abstract type or by any manifest type—to have an 
abstract type supplied by a manifest type is the essence of sealing. A manifest type 
may be supplied either by an identical manifest type or by an abstract type that is 
demonstrably equal to it. A value may be supplied only by a value of the same type, 
and a module of type 7’ may be supplied by a module of the same name whose 
type 7 isa subtype of T’. 


9.8.4 Principal module types, sealing, and realization 


A module can be sealed with any module type whose promises are redeemed by 
the module. Gloriously, every well-typed module has a principal module type that 
is at least as good as any module type whose promises are redeemed by the mod- 
ule. For modules, “at least as good” means “a subtype of’—and, if you study the 
subtype relation, you'll see that it also means “provides at least as much informa- 
tion as.” A principal module type (henceforth, “principal type”) provides as much 
information as possible; it hides nothing. 


msubsn(|EXPORTS(Ds) |) = msubsn(|Ds|-) 
msubsn(|7i A T2\2) = msubsn(|71|7) o msubsn(| 727) 


msubsn(| |x 


) 

) 

) 
msubsn(|t = 7, Ds|,) = msubsn 

) 

) 

) 


(|Ds|x)° (mt 7) 
ee D - Dp §9.8 
msubsn(|t :: |*| 2", Ds|,) = msubsn(|Ds|,) Molecule’s type 
msubsn(|a : 7, Ds|,) = msubsn(|Ds|,,) system: Enforcing 
msubsn(|M : |7|q, Ds|,) = msubsn(|Ds|,) omsubsn(|T |x) abstraction 
0; = the identity substitution 567 


Figure 9.16: Substitution from manifest types 


A module’s principal type is also intersection of all the types that could be as- 
cribed to it. In Molecule, a module’s principal type is unique up to reordering of 
components. The existence of unique principal types is the result of careful design, 
which I have borrowed from the ML family of languages. 

Principal module types are used primarily for sealing. The module being sealed 
is the implementation, and its type is the implementation type. The module type doing 
the sealing is the interface type or just the interface. Before the two can be compared, 
the interface type has to be realized. To see that the interface type can’t always be 
compared directly, consider the example below: module R has principal module 
type (exports [type t Int.t] [x : Int.t]), and it is sealed with an interface in 
which not only is t abstract, but x is given the abstract type R.t, not type Int.t. 
567. (transcript 530b) += 1566 570> 

-> (module [R : (exports [abstype t] [x : t])] 
(type t Int.t) 
(val x 1983)) 
module R : (exports [abstype t] [x : R.t]) 
As illustrated by the Char example at the start of this section, types R.t and Int.t 
are different, but we want the example to be accepted anyway. After all, the inter- 
face places no constraints on type t, and the t and x components demanded by the 
interface are provided by the implementation. 

The type component t is easy to accept; the interface demands an abstract- 
type component t :: |*|p, and the module’s principal type has component t = 
Int.t. According to Figure 9.15, any manifest type t is a subtype of abstract type t. 
All good. 

What about x? The interface demands value component x : R.t, and the im- 
plementation’s principal type has component x : Int.t. Just like types Char.t and 
Int.t, types R.t and Int.t are different, and according to Figure 9.15, one value 
component is a subtype of another only if their types are the same. But inside mod- 
ule R, they are the same—the question is, how does the type system know? Molecule 
uses a technique that is borrowed from Standard ML, called realization. 

An interface is realized by replacing each abstract type with its representation, 
which comes from the implementation. Realization also transforms each abstract- 
type component into a manifest-type component. The type definitions in the im- 
plementation are converted to a substitution by function msubsn (Figure 9.16), 
which is applied to the principal type of the implementation. In the example of 
module R above, msubsn returns the substitution that replaces type R.t with type 
Int.t. 
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= ExPorTS(6(D1),...,9(Dn)) 


t:: |*|,, when 7 ¢ domé 
O(t :: |x| 7) =t = (7), when 7 € dom dé (x) 
O(a: 7) =2%:0(T) 
6(M:T)=M:0(T) 


Figure 9.17: Module-type realization 


The substitution is used to realize the interface by applying it to the interface 
type as shown in Figure 9.17. The equation marked with a star replaces every ab- 
stract type in the interface with its manifest definition from the implementation 
(assuming the type is defined). The other equations are structural. 

Realization and subtyping work together to determine when a module type can 
be used to seal a module; an implementation of principal type 7 defined at path 7 
can be sealed with interface type 7’ if and only if the implementation type is a 
subtype of the realized interface: 


J <smsubsn(|T | )(7 ): 


9.8.5 Computing principal module types 


A module’s principal type is computed by a process that resembles the typecheck- 
ing of definitions in Typed Impcore and Typed jsScheme. But in Typed Impcore 
and Typed psScheme, typechecking a definition produces only a new environment. 
In Molecule, typechecking a definition also produces bindings. These bindings are 
added to the environment, and they can also become components of a principal 
module type. Typically one definition produces one binding; for example, a defi- 
nition of the form (val x e) produces a binding of the form x : 7, where 7 is the 
type of e. But a data definition produces multiple bindings: one for the type and 
one for each value constructor. And typically the bindings produced by a definition 
also declare components in a principal module type, but the binding produced by 
an overload definition doesn’t declare any components. 


The judgment form for checking a definition is | E + |d|c : Ds|, where the 


metavariables stand for the following: 


d The definition 

C The context in which it appears 

Ff The environment in which it is checked 

Ds The bindings or components that it contributes 


The context is used to generate an absolute access path for every defined mod- 
ule and every new type defined by data. For example, in module Intlist below, 
the module definition is checked in the empty context, but the data definition is 


(DEFVAL) 
EF |d|co: Ds ieee 
EF |wat(a,e)|c: |x: 7] 
(DEFVALREC) (DEFTYPE) 
Etre E,x:t'be:7' Etre 
EF |VAL-REC(z: 7,e)|c: [2 : 7'] EF |type(t,7)|o: [6=7'] 
(a) Core-layer definition forms 
(DEFMODTYPE) 
Et |d|c: Ds EF|T|)“T' 
E+ |mopute-tyPe(T,7) |): [T= 7] 
(DEFSEALEDMODULE) 


Er Lds | o[a] eee 


Er LT |otmy ~~ Isuper d= msubsn(Tsup) Tub < OT super 


EF |MopuLe([M : 7], ds)|c : [M : Tsuper] 


(DEFCOPYMODULE) 
Ebr: T 


E+ |MopuLe(M,7)|co:[M:T] 


(DEFRESEALMODULE) 


EF (Tle 


BET: Toup 


[M] “? /super d= msubsn( Tou) Tsube OT super 


Et |mMopute([M :7],7)|o:[M : Tsuper| 


(DEFGENERICMODULE) 


T, =(M1: Tix +++ x (Me: Te] 9 T 
Br lly Te 
Ty =(Mi: 7/1 +--+ x (Me: Th] T’ 
mm = (@mCiM] M, --- Mx) 
EM? Tea cca Megs Ty, EL dale Th, 
6 =msubsn(7y) Ty <: OT" 


E+ |GENERIC-MODULE([M : Tj], ds)|o : [M : Tj] 


(b) Module-layer definition forms 


Et |ds|,: 7 


EF |ds|, : Ds 


EF} |ds|, : EXPORTS(Ds) 


Et |ds|, : Ds 


(NONEMPTYDEFS) 
Er Ld] 1] : Ds! 


E, Ds’ + |ds|_ : Ds” 
dom(C(Ds)) MN dom(Ds"") = 0) 
Ela: {] EF |d, ds] _5C(Ds),Ds" 


(c) Sequences of definitions 


Figure 9.18: Typing rules for definitions 
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BT: Eta:T /x 
(T1 A T2)/m = Ti/a A To/t (t=7)/7 = (t=7) 
EXPORTS(Ds)/m = EXPORTS(Ds/7) (t:: |*|a)/a = (t = 14) 
[]/7 = [] (f.7) (Rae or 
(D, Ds)/nx = D/n, Ds/a (M:T)/m=2:T/n7.M 


Figure 9.19: Strengthening module types and components 


checked in the context Intlist.[]. That context makes the type’s absolute access 
path Intlist.t. 


570. (transcript 530b) += 1567 593> 
-> (module [Intlist : (exports [abstype t] [Nil : t] [Cons : (int t -> t)])] 
(data t 
(Nil : t] 


[Cons : (int t -> t)])) 
module Intlist : 
(exports 
[abstype t] 
[Nil : Intlist.t] 
[Cons : (Int.t Intlist.t -> Intlist.t)]) 


Definitions are checked by the rules shown in Figure 9.18. Because there are 
a lot of definition forms, there are a lot of rules; part (a) shows rules for just the 
core-layer forms. Rule DEFVAL resembles the VAL rule for Typed juScheme; expres- 
sion e is typechecked to have type T, and the result binding list Ds is the singleton 
list [2 : 7]. In other words, x : rT is produced as a binding (and a component). 

Unlike VAL forms, VAL-REC and TYPE forms include types in the syntax, and 
those types have to be checked. A type is checked by a judgment of the form 
E+ + ~ 7’, where type 7 is the type written in the syntax and 7’ is the internal 
representation used in the type checker. The judgment, pronounced “7 elaborates 
to 7’,” produces 7’ by expanding all the type abbreviations found in 7, and it also 
checks that 7 is well formed. Elaboration, which is presented in the next section, 
subsumes the kind checking used in Typed jsScheme (judgment AF 7 :: ). 

With the understanding that types have to be elaborated, rules DEFVALREC and 
DEFTYPE are otherwise similar to DEFVAL: each rule produces one binding. 

In part (b), on module-layer definition forms, the DEFMODTYPE rule resembles 
the DEFTYPE rule. The elaboration of a module type is more involved than the elab- 
oration of a type, and it too is discussed in the next section. And there’s one more 
subtlety: a MODULE-TYPE definition typechecks only when evaluated in the empty 
context | ]. That requirement ensures that module types may be defined only at top 
level. 

The remaining rules typecheck module definitions. The main rule is DEF- 
SEALEDMODULE: a module / is sealed with interface 7 and defined by a sequence 
of definitions ds. Above the line, the first judgment FF | ds | ojyq : Tsup Says that 
the principal type of the implementation is 7,,,». Next, the interface type is elabo- 
rated to produce internal representation 7 super. Then, as described in the previous 
section, the interface type is realized by substituting for every manifest type in 75... 
Provided the principal type is a subtype of the realized interface type, the module 


definition is well typed, and a binding is produced that associates the module with 
its (unrealized) interface type, not with its principal type. This step, in this rule, is 
where a manifest type inside / is converted to an abstract type outside—it’s where 
data abstraction happens. 

Rules DEFCOPYMODULE and DEFRESEALMODULE are similar, except the mod- 
ule’s body is obtained not from a sequence of definitions but from another module 
named at path 7. Judgment F | zm : Tsu» says that the module at 7 has princi- 
pal type 7s.», and that type is obtained in two steps: first the path 7 is looked up 
in the environment, and then the type of the module at that path is strengthened. 
Strengthening converts every abstract type into a type that is manifestly equal to 
itself (Figure 9.19, on the facing page). The strengthening transformation is used 
in the single rule for judgment E' | 7 : 7; both are shown in Figure 9.19. 

Rule DEFGENERICMODULE looks complicated, but it’s more of the same. A ge- 
neric module has to have a module-arrow type, and that type is elaborated to pro- 
duce the internal representations of the argument types 7/,..., 7, and the result 
type 7’. The body of the module ds is checked at path 7, which is the path formed 
by instantiating the module at its formal parameters. (When the module is instanti- 
ated, the formal parameters are replaced by the absolute access paths of the actual 
parameters.) And the body is checked in an extended environment, which has ac- 
cess to the formal parameters. Finally, in the usual way, the body’s principal type 7; 
is checked to make sure it delivers everything demanded by interface type 7’. If all 
is well, the generic module typechecks with the module type claimed for it, anda 
binding is produced with that type. Because a generic module appears only at top 
level, this binding won’t ever be converted to a component. 

Figure 9.18c shows how to check a sequence of definitions in the body of a mod- 
ule. The principal type of a sequence of a definitions is always an EXPORTS type, 
and definitions are checked one at a time. The key rule is rule NONEMPTYDEFS, 
which checks definitions |d, ds |, at path 7. Definition d is checked first, and the 
resulting bindings Ds’ are added to the environment that is used to check the re- 
maining definitions ds. But not everything in Ds’ necessarily contributes a com- 
ponent. The sequence of bindings Ds’ is converted into a sequence of components 
by function C, which is defined as follows: 


C({}) =I] 
C(t =7, Ds) =t =7,C(Ds) 
C(x: 7, Ds) =x: 7,C(Ds) 
C(M :|T|x,Ds) =M:T,C(Ds) 
C(a € [m,.-.,7], Ds) = C(Ds) 


The rule has a side condition: a module may not have duplicate components. 
This condition is enforced by the premise dom(C(Ds’)) M dom(Ds”) = @. In my 
implementation, this condition is relaxed: a value component—and only a value 
component—may be redefined. Redefining a function can be useful when debug- 


ging. 
9.8.6 Elaborating types and module types 


As in Typed wScheme and ML, type syntax written in a program must be vali- 
dated. Because every type in Molecule has kind *, validation is less involved than 
in Typed Scheme or (ML: it suffices if every path is well formed and refers to a 
type. And if such a path begins with an instance of a generic module, the module 
must be instantiated correctly. Molecule’s type checker not only validates syntax 
but also translates it into internal form: it replaces each type abbreviation with its 
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pie eas at EU 7, l<i<n Etre 


ERT XX TOT TX XT 7! 


E2st=T Banrt=rT 
EFtw or Bert. 


(a) Elaboration of types 


BAT. et (ELABINTERSECTION) 
7 (ELABNAMEDMT) Et \fil;no TH 
E=sT=T Et |Taln > Tz 

Ti =(enn)T 6 = msubsn(77 A 73) 

EFT |,;,~T' EF |NA Tala ~ OT] A OTs 
(ELABEXPORTS) (ELABGENERIC) 

Ebr | Ds|_~> Ds’ LE} EF ITln~ T" 

EF |exports(Ds) |, ~» EXPORTS(Ds’) Et |T|];,~T 


(b) Elaboration of module types 


Et [Ds], ~» Ds' Et |D\_ ~~ D’ 


E, B(|D'|2) + | Ds|x ~ Ds’ 
dom(D) NM dom(Ds) = 0 


Eflla~[] Et |D, Ds|, ~ D’, Ds’ 
Et |D\,~ D’ a 
Eb lt:%|_wts [eae BP ter, @t=7 
(ELABSUBMODULE) 
Etre Et |T\|”au~T' 
Et |a:tl,;pwau:t' EF\|M:T\|,;~M:T' 


(c) Elaboration of declarations 


LE | xs 7 var aati 


(ELABGENERICARG) 
n>0O EF |Tila~ 7! 
| EB, .My : Ti |asm, & (M2: Tz) x +++ X (Mn: Tn) “3 Tle 
(Mo: TZ) x =* x (My i Ti) ST’ 
[East (My: Ti) x +--+ x (My: Tn) “> Thaw 
(My : Ti) x ++» x (Mn: Tf) 3 T' 


(ELABGENERICRESULT) 
BY LT | (mm ms) “7 Te 


LE Jas |>T)h~ oT! 


(d) Elaboration of generic module types 


Figure 9.20: Elaboration 


B([D],)=D' B(lt=T\|n)=t=7 
B( [t= [Ala |e) =t= 7! 
B(ja:t|r7)=@:T 

Bla: Tlr)=2e: (Tle 


(abstract component becomes manifest) 


Figure 9.21: Conversion of component to binding 


referent and each relative access path with the corresponding absolute access path. 
This kind of translation is called elaboration. If a module type is elaborated success- 
fully, it is well formed. 

Types are elaborated by the rules shown in Figure 9.20a (on the facing page). 
A function type is elaborated structurally, and a path is elaborated by looking it 
up in the environment. Lookup, whose judgment form is L 5 D, is specified in 
Figure 9.22 (page 574). 

Module types, in Figure 9.20b, are more involved. They are elaborated by judg- 


ment form | + |7 |, ~» 7’| which requires an absolute path 7 as a context. 
In rule ELABNAMEDMT, this path is used to “re-root” module types and abstract 
types that aren't yet associated with any absolute path. Such types come from 
module-type abbreviations J. = 7. The other rules are primarily structural, but 
some rules have fine points or entail additional transformations: 


+ When an intersection type 7; A 72 is elaborated, any exported type that is 
manifest in either module type is made manifest in both types, using msubsn. 
Intersection is typically used to refine the result type of a generic module; 
for example, in the definition of the ArrayHeap module in chunk 552a, the 
elaboration of the intersection type converts the result’s abstract type elem 
into a type that is manifestly equal to Elem.t. 


* When the structural elaboration works its way down to an EXPORTS type 
(rule ELABEXPORTS), the exported declarations are elaborated one by one in 
sequence (Figure 9.20c). Once a declaration is elaborated, it is also added to 
the environment, for which purpose it is converted to a binding. Each defini- 
tion is converted by function 5, which treats every abstract type as an abbre- 
viation for its absolute access path (Figure 9.21). For example, when module 
type 2DPOINT is elaborated (chunk 531a), the abstract type t is first added to 
the environment as an abbreviation for its absolute access path e.t. Next, 
when declaration for new is elaborated, it gets type (Int.t Int.t -> e.t). 


+ A sequence of declarations elaborates successfully only if it contains no 
duplicates. This condition is enforced in Figure 9.20c by the condition 
dom(D)N dom(Ds) = 9. 


* When the declaration of a nested module J is elaborated, the type system 
tracks the absolute access path of its type 7 by extending the context to 7. M 
(rule ELABSUBMODULE). 


Elaborating a module-arrow type requires some extra context. In judgments 


of the form] |E |r; [7 |x ~ 7" |, the list of paths 7s names the formal parame- 
ters. This list is accumulated in rule ELABGENERICARG, and in rule ELABGENERIC- 
RESULT, the qualified name (@m 7 7s) is used to re-root the result type. 
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EH>3D (LOOKUPBINDING) 
dom(E’) N dom(D) = 6 
E,D,E'>D 


(LOOKUPMANIFESTTYPECOMPONENT) 
Ean: |T\x7 t=7 €comps(7) 
BE anrt=T 


(LOOKUPABSTRACTTYPECOMPONENT) 
Ean: |T\e ts |e] av © comps(T) 
E 2 nrt=n" 


(LOOKUPVALUECOMPONENT) 
E2an:|T\e «£:7 € comps(7) 
EDW.0:T 


(LOOKUPMODULECOMPONENT) 
Ean:|T\a M:|T' |e © comps(T) 
BE 2>7.M: [T" | at 


(LOOKUPINSTANCE) 
Eom: (Mi: T]) x: (Mn? Th) OT 
Etm:Ti, 1<i<n 
(My: Ty) x & (My Te) Se FOU The tat Te) oT" 
E> (@m 771 +++ Tr)? healer ots Wn) 


(My: Ty) x & (My Tl) SS FOG Tita tT) 2 T" 


(INSTANTIATE) 
Om, = msubsn(7;) 6, = (Mi om Th <: Om (0-77) 
((Mz : 0-73) X «++ X (My : O77) 9 Om(OrT"))@( 12 : Ta°++ in Ta) 2 T" 
(My: 7) x ++) x (My: Tj) “> T)@(m1 : Th ++ tn: Ta): T" 


S 


(BT 0:7" 
Figure 9.22: Path lookup in the environment (D stands for a binding) 


And when a module-arrow type is elaborated, the first formal parameter (1; 
may be referred to in the types of any of the subsequent formal parameters or in 
the type of the result. In rule ELABGENERICMT, after 7; is elaborated to 7,’, the 
arrow type is elaborated in an environment extended with the binding 7.Mj : T/. 


9.8.7 Environment lookup and instantiation of generic modules 


As shown in Figure 9.13 (page 562), a name in an environment may be bound to a 
type abbreviation, a value, a module, a module type, or a set of overloaded types. 
A name is looked up just as in any other chapter: lookup finds the most recent 
binding in the environment. But in this chapter, lookup isn’t written E(t) = 7 
or F(a) = 7; such notation would make it hard to distinguish a type binding 


from a value binding. Instead, lookup is written using a containment relation like 
E>t=tTor£F 32:7, or inthe general case FE 5 D.* The 5 notation has an- 
other advantage: it can be extended to describe the result of looking up an access 
path in the current environment—which is what is meant by a relative access path. 
Environment lookup is described by the rules in Figure 9.22 (on the facing page). 
Rule LOOKUPBINDING describes standard environment lookup: any binding D can 
be looked up by name, but it may not be superseded by a binding to its right (in E’). 
The next four rules describe lookup of a module component using its path, which 
may refer to a manifest type, an abstract type, a value, or a module. At lookup time, 
each abstract type is converted to a manifest type by making it manifestly equal to 
itself. (As noted in Figure 9.13, an abstract type may be a component but not a 
binding.) 

Paths also include instances of generic modules, which are governed by the 
INSTANTIATE rule. When the generic module expects multiple parameters, the 
rule uses a crazy amount of substitution, but in the special case where the generic 
module expects just one parameter, the rule is simpler: 


(INSTANTIATEWITHONEPARAMETER) 
Ean:(M,:T/) 3 T Bram: 
0, = (M1 4 77) Oy, = msubsn(7;z) 
Th <: O0m(0+T/) T" =On(6-T') 
E> (ema 74): [| cena cas 


The specialized rule works like this: 


* The module being instantiated is 7, and it has a module-arrow type with one 
formal parameter M, of type 7;'. The actual parameter 7, has type 7}. 


* The module type of the formal parameter, 77, can include references to 
type components of that parameter. For example, in the generic mod- 
ule ArrayHeap defined in chunk 552a, the formal parameter is Elem, and 
type 7, declares a value <= of type (Elem.t Elem.t -> Bool.t). Module 
ArrayHeap can be instantiated with actual parameter Int only because Int.t 
and Elem.t are the same. The identity is demonstrated by “re-rooting” mod- 
ule type 7,’ using substitution 0,, which maps Mj, to 7. In the example, 
it maps Elem to Int. 


* Once the module type of the formal parameter is re-rooted, the actual param- 
eter is checked using subtyping, just as when sealing. And as when sealing, 
Om, substitutes for every manifest type in 7. In the example, the module 
type of the actual parameter, Int, doesn’t have any manifest types, so 0, is 
the identity substitution. 


Provided the subtyping test passes, the instantiated module has type 7”. 
Type 7” is obtained by taking the result type 7’ from the module-arrow type, 
then substituting both for /; and for any manifest types that occur in 7}. 
The substitution says, for example, that in module (@m ArrayHeap Int), type 
elem is an abbreviation for type Int.t. 


If the types of generic modules were curried, so that a generic module al- 
ways took exactly one parameter, the special-case rule would be enough. Multi- 
parameter modules require more bureaucracy. Actual parameters 71,..., 7, are 
checked one at a time against formal parameters Mj,..., M,. And the type com- 
ponents of actual parameter 7 can be referred to not only in the result type 7’, but 


4Here D stands for a binding, which resembles a declaration or component. 
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EF |dlo: Ds Br awae:T 


FE does not overload x 


E+ [OVERLOAD(7.2)|co : x € [7] 


Br aa: 
E 2xe€([n,...,7r 
E+} |OvERLOAD(7.2)|o : @ € [7,71,.-+5 Th 


(a) Typing rules for overload definition 


a : 
Bhewéin, 1Si<n 


E2a€ [r,..-, 7%] 
TST XX TOT 
Ak: k<jAman xXx! or” 


EF appiy(z,€1,...,€n) ~ APPLY(Z,€1,...,€n)5 17 


Ereweéi:t, 1<i<n 
BDUL:% X+++XTMmAOT 


EF ApPLy(e, €1,...,€n) ~» APPLY(e,€4,...,€),) 37 


(b) Elaboration of function application, with overloading 


(e, p,o) I (v, 0") (x, p,o) | (fur, ..., Up], 7) 
Uj = (LAMBDA((@1,...,2n),€c), Pe) 
(€1, P, 70) a (v1, 01) ibe (Cn, P, On—1) { (Un, On) 
£1,...,€n € dom oy (and all distinct) 
(€c, Pe{@1 > £1,...,2n > En}, onf{lr OF U1, --.,Ln OF Un}) | (v, 0’) 
(APPLY(2, Ely+++s en) 35; P; o) (v, a’) 


(c) Evaluation of overloaded application 


Figure 9.23: Overloading 


also in the types of later formal parameters M2 to M,,. So after each actual param- 
eter, substitutions 6, and 6,,, have to be applied not only to the result module type, 
but also to the remaining formal parameters. To apply those substitutions correctly 
requires an auxiliary judgment, which takes up the last two rules in Figure 9.22. 


9.8.8 Overloading 


Molecule’s overloading is just a quick hack. In any given typing environment F, 
each overloaded name is associated with a sequence of types. In the evaluation en- 
vironment p, that same name is associated with a sequence of values—one for each 
corresponding type. The associations are made, respectively, during the elabora- 
tion of and during the evaluation of an OVERLOAD definition. Elaboration is shown 
at the top of Figure 9.23: if name z is not already overloaded, the elaborator asso- 
ciates it with the singleton sequence T. If x is already overloaded, the elaborator 
adds type T to the existing sequence. Evaluation, which is not shown, works simi- 
larly. 


At run time, an overloaded name is evaluated with the help of bread crumbs left 
by the type checker. Molecule’s type checker checks expressions using rules that 
are essentially identical to the rules for Typed wScheme, and in addition, it deco- 
rates every application of an overloaded name. Decorations are added during elab- 
oration, which is described by judgment EF’ | e ~ e’ : Tr, pronounced “e elaborates 
to e’ and has type r.” If an overloaded name 1 is the function in an APPLY expres- 
sion, the expression is decorated with an index j7, which shows which overloaded 
type is selected for x. 

A decoration is added to an APPLY node by the first rule in Figure 9.23b. Each 
actual parameter e; is typechecked and decorated, and the possible types of x are 
enumerated as [T],...,7;,]. One of those types, 7;, is a function type whose first 
argument has type 7), which is the type of e;. And the other e;’s have the types 
of the other arguments in type Ts The final premise takes the first T} whose first 
argument has type 7,. This premise, or something like it, is needed to make the 
semantics deterministic. (For a better algorithm, see Exercise 51.) 

If x is not overloaded, or if a function is applied that is not a simple name, then 
the second rule applies. This rule is like the rule for typechecking an application 
in Typed puScheme, except that each argument may be decorated. 

When an APPLY expression is decorated with an index 7, itis evaluated specially 
(Figure 9.23c). The overloaded name z evaluates to a sequence of values [v1,... , Ux]! 
one for each type at which x was overloaded during the typechecking phase. 
The correct value v; is selected by the decoration on the APPLY node. Assuming 
that v; is a closure, as shown in the rule, evaluation proceeds as in Scheme or 
Typed pScheme. 

The elaboration of expressions and definitions is ignored by the typing rules 
that appear earlier in this section. Those rules pretend that expressions and defi- 
nitions need only to be typechecked, not decorated. The pretense amounts to the 
assumption of a rule like 


Ekewe:t 


Ebre:T 


But when a definition of the form VAL(z, e) is typechecked in the interpreter, every 
expression is elaborated. 


9.8.9 Analysis of the design 


Molecule’s type system works can usefully be compared with other type systems 
along three dimensions: polymorphism, generativity, and substitution. 


How polymorphism works: Molecule and Typed Scheme compared 


Typed uScheme, nano-ML, and Molecule demonstrate three approaches to stati- 
cally typed polymorphism: 


* In Typed pScheme, every type abstraction and instantiation is explicit. The 
resulting language is very expressive—polymorphism is impredicative, which 
means that a type variable can be instantiated with a polymorphic value. But 
the language is painful to use. It’s especially painful to have to instantiate 
every polymorphic function before it can be used. 


In nano-ML, polymorphism is predicative, which means that a type variable 
may not be instantiated with a polymorphic value. Moreover, the argument 
to a function may not be polymorphic. The resulting language, while less 
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expressive than Typed juScheme, is plenty expressive enough for many pur- 
poses. And itis a joy to use: the type checker automatically instantiates every 
polymorphic function at its point of use, and it even infers polymorphic types 
where possible. 


* In Molecule, type abstraction is replaced by module abstraction (generic 
modules). And instantiation is done one module at a time, not one value 
at a time. Polymorphism is predicative, meaning that the argument to a ge- 
neric module may not itself be generic. And the language is pleasant enough 
to use: once a generic module is instantiated, its functions can be used arbi- 
trarily many times without further bureaucracy. 


The relationship between Typed wScheme and Molecule warrants a more tech- 
nical comparison. 


* Both type systems have a function type (in the interpreters, FUNTY). 


* Both type systems have type constructors of kind +. In Typed pScheme, 
a type constructor is represented by its name. In Molecule, a type construc- 
tor is represented by its absolute access path. 


* Both type systems have abstract “type formers” of higher kinds, like “list” or 
“array.” Such an abstraction is not a type by itself, but once supplied with ac- 
tual parameters, it can produce a type. In Typed Scheme, the abstraction 
is a type constructor of kind * > x, or of any other kind with an arrow in it. 
In Molecule, the abstraction is a generic module—that is, a module whose 
module type has an arrow in it. In Typed sScheme, a type constructor pro- 
duces a type when it is applied. In Molecule, a generic module produces 
a type when it is instantiated and a type component is selected from the in- 
stance. These constructions are analogous; for example, the Typed zScheme 
type (array boo1) is analogous to the Molecule type (@m Array Bool).t. 


* Both type systems can create a polymorphic value by abstracting over un- 
known types, and both enable code to refer to an unknown type by name. 
In Typed wScheme, a polymorphic value is introduced by a type-lambda, and 
the unknown type is named by a type variable written in the type-lambda. 
In Molecule, a polymorphic value is not introduced directly; instead, Mol- 
ecule code introduces a generic module, then selects a value component. 
The unknown type is a type component of an unknown module, which is 
named by a formal module parameter in the generic module. 


In effect, except for impredicative polymorphism, Molecule can do everything that 
Typed Scheme can do. Andimpredicative polymorphism is relatively easy to add, 
provided you avoid trying to intersect the types of generic modules (Leroy 2000). 


Generativity 


Molecule’s module definitions are generative, in the sense explained in Section 8.5 
(page 483): every module definition introduces new types, even if the module is 
defined with the same name as a previous module. Generativity is not expressed in 
Molecule’s type system as it is presented in this section—to track it would require 
so much bookkeeping that the main ideas would be hard to follow. For that reason, 
the type system as presented is sound only under the assumption that every module 


has a distinct absolute access path. Under the covers, my implementation makes 
it so: 


+ A path may begin with a module identifier Y , which cannot be written in the 
syntax. 


* The elaboration of a module definition introduces a fresh module identifier. 
A fresh module identifier is also introduced for each formal parameter of a 
generic module. 


* During elaboration, every path that appears in the syntax is elaborated into 
an absolute path, which begins with a module identifier. 


The uniqueness of the module identifiers ensures the uniqueness of every abso- 
lute access path, which makes module definitions generative and helps guarantee 
soundness. 


An alternative design: Type checking without substitutions 


Molecule enforces type abstraction by making sure that outside a module, an ab- 
stract type looks different from its definition—and types that look different always 
are different. When types look different but actually are the same, like int and 
Int.t. Molecule makes them the same via elaboration and substitution: int is re- 
placed by Int .t; references to manifest types are replaced by their definitions; and 
when a generic module is instantiated, the formal parameters are replaced by the 
actual parameters. But substitution is nobody’s favorite mechanism: it can be hard 
to get right, and when substitution is used in an inference rule, what it’s doing is 
not always obvious. Substitution is a good choice for this chapter because it keeps 
the type system consistent with the type systems presented in Chapters 6 and 7, 
but a nice alternative is to define type equality and subtyping in a way that is not 
consistent with Chapters 6 and 7: they can depend on context. 

This alternative, designed by Leroy (2000), extends the core-layer type system 
with a contextual type-equality judgment F | + = 7’, and it replaces the module- 
layer subtyping judgment with the judgment E+ T <: 7’. These judgments have 
access to all the type equalities in environment F; for example, Molecule’s initial 
environment Eo supports the judgment Fo | int * Int.t. Making these judg- 
ments contextual enables Leroy’s system to check ascriptions without substituting; 
for example, instead of extracting a substitution from the manifest-type declara- 
tions of a module, his system puts those declarations into L. The system is elegant, 
but its test for type equality is so different from the tests in Chapters 6 and 7 that it 
is a poor fit here. 


9.9 NOTES ON THE INTERPRETER 


As you might guess from the size of the type system, Molecule’s interpreter is a 
beast; it’s about the size of the interpreters for Typed jzScheme and sML combined. 
But the type checker uses the same techniques that are used in Typed jsScheme, and 
the evaluator uses the same techniques that are used in sML, so the code doesn’t 
have much to teach you. The interpreter is therefore relegated to the Supplement. 
Should you choose to study it, its most salient aspects are as follows: 


* Many syntactic forms have two representations: one for the form as it ap- 
pears in the source code and one for the form as it appears after elaboration. 
They are, for example, pathex and path, tyex and ty, modtyex and modty, 
and so on. 
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+ Expressions have only one representation; in that representation, the APPLY 
node includes a mutable cell. This cell holds the decoration, if any, that iden- 
tifies the resolution of an overloaded name. Elaboration is implemented not 
by translating from one representation to another but by updating that cell. 


* The implementation includes a type not shown in Section 9.8: type ANYTYPE 
is the type assigned to an error expression. Type ANYTYPE is uninhabited, so 
it is compatible with any type. 


* In the implementation, unlike the type theory, declarations, components, 
and bindings have different representations: dec1, component, and binding. 
In the theory, blurring the distinction simplifies the notation and makes the 
ideas easier to follow. In the code, enforcing the distinction helps me get the 
invariants right. 


9.10 ABSTRACT DATA TYPES, MODULES, AND OVERLOADING AS THEY RE- 
ALLY ARE 


Different languages provide abstract data types and modules in very different ways. 
To add to the potential confusion, many languages, including Java, C++, Modula-3, 
and Ada 95, combine abstract data types with objects. In this section, I stick to 
abstract data types: I enumerate some major design choices, I describe what I con- 
sider the best choices, and I describe a key mechanism that’s not included in Mol- 
ecule: exceptions. I also say a few words about overloading. 


Major design choices 


Designs for abstract types and modules vary along many dimensions. The impor- 
tant variations can be identified by a litany of questions. When you encounter a 
new language, the questions will help you understand what you're dealing with. 


* Can an interface be written (and compiled) separately from any implementation? 
In the Modula family, Ada, Java, the ML family, and Molecule, yes. In CLU, 
Oberon, and Haskell, no. (This is the key question, about which I rant below.) 


* Can modules be generic? In Modula-3, Ada, and the ML family, yes. In Modula-2, 
Oberon, and Haskell, no. (In C++, Java, and CLU, you will find some form of 
generics, but not exactly modules.) 


* Do generic modules support modular typechecking? That is, can you typecheck 
a generic module and its arguments separately, then combine them? (If not, 
only instances can be typechecked.) In the ML family, Java, and Molecule, 
yes. In Modula-3 and Ada, no. And in C++, templates don’t support modular 
typechecking. 


Is instantiation generative? That is, if a generic module is instantiated with the 
same arguments, in two different places, are the resulting instances differ- 
ent? In Ada, Modula-3, and Standard ML, yes. In OCaml and Molecule, no. 


* Can a module be defined without being sealed by an interface or an export list? 
In Ada, CLU, the Modula family, Oberon, and Molecule, no. In Haskell and 
in the ML family, yes. 


* Can a module export manifest types as well as abstract types? In CLU, no. In all 
subsequent languages, yes. (Modula-3 has an especially nifty mechanism, 
the partial revelation, which can expose selected information about a type.) 


* Does every module have a name? In CLU, Ada, the Modula family, Oberon, 
Haskell, and Molecule, yes. In the ML family, no—modules can be anony- 
mous. 


* Can modules nest? In CLU, Ada, the Modula family, and Oberon, no. In the 
ML family and Molecule, yes. And in Haskell, a module cannot nest inside 
another module, but the name space of modules is hierarchical, which gives 
the appearance of nesting—and some of the same benefits. (When a system 
grows large, nested modules help programmers avoid naming conflicts.) 


* What are things called? An interface has been called a “signature” (Stan- 
dard ML and OCaml), a “module type” (Molecule and OCaml), a “defini- 
tion module” (Modula family), a “package specification” (Ada), an “inter- 
face” (Java), and who knows what else. An implementation has been called 
a “structure” (Standard ML and OCaml), a “module” (Molecule and Haskell), 
an “implementation module” (Modula family), a “package body,” (Ada), and 
who knows what else. A generic module has been called “generic” (Mole- 
cule, Modula-3, Ada) and a “functor” (Standard ML and OCaml). 


In any given language, many of these questions will be answered differently than 
they are in Molecule, but experience with Molecule will still give you a feel for con- 
sequences. However, that experience won't teach you just how good generic mod- 
ules are when they are paired with a polymorphic core layer, as in Standard ML 
and OCaml. 


Choices to look for 


The design choices that matter most are those that determine how you express or 
discover what operations a module exports. Can you work with a separately com- 
piled interface, or do you have only the implementation? Ideally, you can write 
client code based only on an interface, and you don’t need to look at an implemen- 
tation. But there are trade-offs: 


* When names, types, and other information are explicit in the interface, 
all the information needed to write client code is gathered in one place, 
and the cognitive load involved in understanding the interface is indepen- 
dent of the size of the implementation. I claim that when interfaces are de- 
fined in this style, you can work with larger systems than you could other- 
wise. Other designers agree; for example, the designers of Modula-3 write, 
“To keep large programs well structured, you either need super-human will 
power, or proper language support for interfaces” (Nelson 1991, §1.4.1). 


When there is no interface, only an implementation, there might still be a 
tool that extracts types from the implementation, perhaps even putting the 
results on Web pages; if you use C++ or Java, you may know Doxygen and 
Javadoc. Such tools help limit cognitive load, but I claim that they are still in- 
ferior to designs that enable programmers to write and typecheck interfaces 
separately. System design is interface design, and if you can’t write an inter- 
face and have it checked by the compiler, you’re missing a valuable design 
tool. 


While I favor separately compiled interfaces, I acknowledge that they come 
at a cost. The primary cost is that type information in the interface is often 
repeated in the implementation. Sometimes it is even repeated verbatim. 
I find this cost acceptable, but reasonable designers disagree. 
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Designers of popular languages are found in both camps—sometimes even a 
single designer is in both camps. For example, Java has had separately compiled 
interfaces from the beginning, but for many years C++ had only .h files, which mix 
details of interface and implementation. Twenty-five years after its introduction, 
however, C++ acquired “concepts,” which constrain uses of C++ templates in some- 
what the same way that module types constrain the instantiation of generic mod- 
ules. (The template is a C++ mechanism that supports polymorphism—and much 
else besides.) 

As another example, Niklaus Wirth, designer of Pascal, Modula-2, and Oberon, 
has made different choices at different times: standard Pascal has no modules or 
interfaces; Modula-2 has separately compiled interfaces; and Oberon has no inter- 
faces, not even an export list. (In Oberon, exported names are those marked with 
a * in the implementation.) 

The programming language Go makes a similar choice to Oberon: names be- 
ginning with capital letters are exported—but in Go it is also possible to declare an 
interface type, which enumerates operations associated with an abstract type. 

Among popular functional languages, languages in the ML family work both 
ways: you can write interfaces if you want to, and where you don’t, the compiler 
infers them. By contrast, Haskell works like CLU: exported names are listed, but 
information about their types must be gleaned from the implementation. Some of 
Haskell’s designers regret this choice: 


Haskell 1.4 completely abandoned interfaces as a formal part of the 
language; instead, interface files were regarded as a possible artifact 
of separate compilation. As a result, Haskell sadly lacks a formally 
checked language in which a programmer can advertise the interface 
that the module supports (Hudak et al. 2007, §8.2). 


Distinct, separate interfaces are a great starting point for any design. But Ihope 
for more: 


* In a good design, any implementation can be typechecked given only the 
interface it implements and the interfaces it depends on—without need- 
ing other implementations. This feature enables abstractions to be imple- 
mented from the top down. For example, if I am designing a Web applica- 
tion to search the text of this book, I should be able to describe the index 
using only an interface, then write the search module that uses the index, 
and finally the build module that creates the index. I should be able to re- 
fine my design without being required to implement the index abstraction. 
Why? Because if there is no implementation, I can change the interface at 
almost no cost—for example, if I decide that the search module needs to be 
able to ask the index about fragments of words, not just whole words, I just 
change the index interface. If an implementation were required, then every 
time I changed the interface, I might have to change the implementation to 
match. 


Independent typechecking is key, but an implementation doesn’t have to be 
compiled independently of all the others. While independent compilation 
sounds nice, performance is often better when the compiler can look across 
module boundaries—to inline small functions, for example. 


If all implementations typecheck, it should be possible to compile and link 
them without any chance of a type error or other compile-time error. 


+ Asingle interface should admit of more than one implementation, and when 
I put together a program, I should be able to choose which implementation 
of each interface I wish to use. 


These criteria are most likely to be met by a language that offers generic mod- 
ules with modular type checking, like Molecule. And in practice, most statically 
typed languages intended for large-scale use meet most of these criteria—but I’m 
not aware of any language that does it all well. In most cases, meeting the crite- 
ria requires mechanisms that lie outside the programming language; for example, 
interfaces and implementations may be required to be stored in files with conven- 
tional names. Or as another example, a separate language may be required just to 
explain how modules should be linked together to form a program. 


When computation can’t continue: Exceptions 


In one way, Molecule illustrates modules and abstract data types badly: it lacks 
exceptions. Exceptions give an operation a way to respond when it can’t return a 
result. For example, if asked to look up a key in an empty dictionary or to produce 
the smallest element in an empty priority queue, an implementation can raise an 
exception. Molecule is limited to other responses: An operation can return a value 
of sum type, like the option type; it can halt with a checked run-time error; or it 
can invoke a failure continuation. Each of these alternatives causes problems for 
client code: 


+ Ifan operation returns a value of sum type, every client has to deconstruct it 
with case. That’s a lot of case expressions. Plus, nothing inherent in a sum 
type suggests that one of the cases represents an important error, or that 
perhaps a special action is called for. 


* If an operation halts, every client has to protect against the possibility. 
For example, every call to delete-min must be protected by a call to empty?. 


* If an operation invokes a failure continuation, every client has to be written, 
at least a little, in continuation-passing style. Nobody wants to read that. 


All three alternatives lead to annoying code, especially in a language without first- 
class, nested functions.° 

Languages like C, C++, Java, and Modula-3 offer another alternative: because 
abstractions are represented by pointers, an operation with no other recourse can 
often return a null pointer. In Molecule, CLU, Haskell, and ML, by contrast, there 
is no such thing as a null pointer. We should be grateful; Tony Hoare, the inventor 
of the null pointer, called it a “billion-dollar mistake” (Hoare 2009). Exceptions are 
better. 

Exceptions appear in many major languages, including Ada, C++, Haskell, Java, 
ML, and Modula-3. Exceptions are typically supported by two syntactic forms, var- 
iously called raise and handle, signal and except, throw and try-catch (Sec- 
tion 3.2.2, page 207), or similar names. The handle/except/try-catch form defines 
a handler, inside of which code is evaluated. When a raise is evaluated, it termi- 
nates the evaluation of an expression, statement, or code block, and it transfers 
control to the nearest enclosing handler. If the raise is not enclosed in a handler 
in its own function, then it terminates the evaluation of its function and looks for 
a handler in the caller. If the call site isn’t enclosed in a suitable handler, then 
the caller is terminated as well, and this computation—unwinding the call stack— 
continues until it reaches a call site that is enclosed in a suitable handler. 

As an example, interpreters from Chapter 5 onward raise the RuntimeError ex- 
ception in many places, and in each case, the call stack is unwound until control 


5If you have true higher-order functions, you can design a lot of code around a polymorphic error 
type like the one in Appendix H, and some of the suffering caused by working with sum types can be 
mitigated by higher-order functions like >>= and >>=+, which are defined there. 
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reaches the handler in the read-eval-print loop. At that point, the read-eval-print 
loop prints an error message, and evaluation continues with the next definition. 

Exceptions have been used in different ways at different times. Exceptions 
as we know them originated with CLU, but CLU imposed two restrictions that we 
would find severe today: in CLU, the set of exceptions a function can raise must 
be enumerated in that function’s type, and every exception that a function might 
raise must be handled by its caller. These restrictions enabled a remarkably ef- 
ficient implementation: Adding a handler to a statement entailed no cost at run 
time, and raising an exception, at least on machines of the day, cost barely more 
than using return. In particular, an exception could be raised without having to 
allocate anything on the heap. 

CLU’s exceptions were intended for more than just errors; they were recom- 
mended to be used to ensure that every operation does something well-defined on 
every argument in its domain. For example, exceptions were used to indicate such 
ordinary, non-error situations as hitting end of file on input, not finding a name in 
an environment, or trying to choose a value from an empty set. 

Things have changed. While in some languages the exceptions a function can 
raise are still part of its type, we no longer require every caller to handle every pos- 
sible exception. And raising an exception has gotten more expensive—for example, 
the designers of Modula-3 recommend to spend a thousand instructions per excep- 
tion raised if that expenditure will save one instruction per procedure call (Nelson 
1991). Moreover, attitudes have changed. Many respected programmers believe 
that exceptions should be reserved for truly exceptional events. I personally find 
that routine use of exceptions leads to cleaner interfaces, but I know that the cost 
models aren’t what they were in CLU. If I intend to use exceptions routinely, I pay 
close attention to costs. 


Overloading as it really is 


From the time there has been floating-point arithmetic, language designers have 
wanted operators like + to mean either integer or floating-point arithmetic, depend- 
ing on the types of arguments. Early designs were ad hoc and often unsatisfying; 
for examples, look no further than the two implementation languages of this book: 
C and Standard ML. 

In the 1970s, CLU took a nice step forward: CLU uses overloading to define a 
whole bunch of syntactic forms—including not only infix operators but also dot no- 
tation and assignment statements—as notations for function application. CLU’s no- 
tations work equally well with both built-in types and user-defined types; CLU over- 
loads a fixed set of syntactic forms, each of which takes a fixed number of argu- 
ments, by dispatching each one to a well-known qualified name, as determined by 
the type of the first argument. For example, an expression of the form e, + €2 is 
rewritten to function call M.add(e,, e2), where M is the module that defines the 
type of e;. CLU’s mechanism inspired the algorithm I use in Molecule. 

In 1981, Ada extended overloading to include not just a fixed set of syntactic 
forms (often called “operator overloading”) but also user-defined functions (often 
called “function overloading,” or in Ada jargon, “subprogram overloading”). Ada’s 
overloading was notable for two innovations: first, user-defined functions could 
be overloaded not just based on the types of the arguments but also on the num- 
ber of arguments—something not necessary when overloading a syntactic form 
like exp + exp, which always has exactly two subexpressions. Second, and more 
startling, functions could be overloaded based on their result types, enabling the 
context in which a call appears to influence what function is called. Ada’s ideas for 


overloading were adapted for use in both C++ and Java, although neither C++ nor 
Java supports overloading based on a result type. 

In the 1990s, Haskell adopted a mechanism proposed by Wadler and Blott 
(1989): functions are overloaded using type classes. A type class can be used to over- 
load any name; because a Haskell “operator” is just an ordinary function name 
written in infix notation, type classes provide both operator overloading and func- 
tion overloading. Type classes defy simple description, but their most important 
element is a relation that says “this type implements this operation using this func- 
tion.” The relation is established using an instance declaration; for example, an in- 
stance declaration can be used to establish that machine integers implement + us- 
ing a primitive function, while complex numbers implement + using a function 
that independently adds the real and imaginary parts. Crucially, an instance dec- 
laration takes the form of an inference rule; for example, Haskell includes a rule 
that says, in effect, that if 7 is a type that implements print, then “list of T” is also 
a type that implements print. The rule also says how to construct the print func- 
tion for a list of r. Type classes are worth mastering; the ability to tell the compiler 
to construct new functions by combining inference rules has had implications far 
beyond the original goals of overloading. For a nice example, see Claessen and 
Hughes (2000). 


9.11 SUMMARY 


Abstract data types as we know them are descended from CLU, whose designers’ 
goal was “to provide programmers with a tool that would enhance their effective- 
ness in constructing programs of high quality—programs that are reliable and rea- 
sonably easy to understand, modify, and maintain” (Liskov et al. 1977). Abstract 
data types and modules separate concerns and hide information, limiting the scope 
of modifications. 

By focusing attention on abstractions and their operations, not representa- 
tions, abstract data types and modules make programs relatively easy to under- 
stand. Ideally, focus can be directed by an explicit interface, like a module type, 
which can be written, read, and typechecked independently of any implementation 
that it describes. 

Any form of abstract data type has a public name but a private representa- 
tion. Access to the representation is limited to operations defined inside some 
sort of syntactic “capsule,” like a module. But within the capsule, each operation 
can inspect the representation of every argument of the abstract type. And be- 
cause access is granted by type, defining an operation that takes multiple abstract 
arguments—like the sum of two arbitrary-precision integers or the merge of two 
leftist heaps—is easy. 

The major limitation of abstract data types is that every access is controlled by 
a static type, and every representation is fixed by a static type. Strict access control 
means that different implementations of similar abstractions do not interoperate; 
for example, a machine integer cannot be added to an arbitrary-precision integer. 
Interoperation is possible only if a programmer inserts explicit coercions. And a 
new representation can be added to an existing abstraction only by modifying the 
source code, which may change the cost model or even the interface. 


9.11.1 Key words and phrases 


ABSTRACT DATA TYPE A form of DATA ABSTRACTION that operates using a static 
type system. An abstract data type has a public name and a private REPRE- 
SENTATION. The representation is visible only inside a syntactic “capsule,” 
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like a MODULE. Operations defined within the capsule have access to the 
representation of any value of the abstract type. 


ABSTRACTION A thing in the world of ideas, or its realization in the computer as a 
value of ABSTRACT DATA TYPE. An abstraction is often specified by appeal to 
mathematical objects like sets, sequences, and finite maps, but it can also be 
specified by axioms or by algebraic laws, or even informal English. 


ABSTRACTION FUNCTION A map from a REPRESENTATION to the ABSTRACTION it 
is supposed to represent. The abstraction function is defined only on val- 
ues that satisfy the REPRESENTATION INVARIANT. Explicit thinking about ab- 
stractions and abstraction functions helps programmers get their code right. 
An abstraction function can also be used to help prove code correct. 


API All the information needed to write CLIENT code that uses an ABSTRACTION. 
Not just a list of exported operations and their types, an API also says how 
each operation behaves and when it is permissible to use it. Also called a 
COMPLETE API. 


CLIENT Code that uses the operations of an ABSTRACTION and does not have access 
to the abstraction’s REPRESENTATION. 


DATA ABSTRACTION The practice of characterizing data by its operations and their 
specifications, not by its REPRESENTATION. 


ENCAPSULATION A term with disputed meaning. Variously used to mean “in- 
formation hiding,” “data abstraction,” or “programming-language mecha- 
nism for enforcing information hiding or data abstraction.” Useful pri- 
marily because it includes the idea of a syntactic CAPSULE within which 
a representation is exposed. Capsules are provided in various languages 
by constructs called cluster (CLU), class (Simula 67, Smalltalk), module 
(Modula-2, Modula-3, OCaml), form (Alphard), and package (Ada). 


GENERIC MODULE A polymorphic MODULE that can be specialized or instantiated 
by providing one or more argument modules. Especially useful for general- 
purpose, reusable data structures. 


IMPLEMENTATION Code that implements the operations of an ABSTRACTION and 
has access to the abstraction’s REPRESENTATION. 


INFORMATION HIDING A principle that encourages designers to build systems 
from parts whose awareness of each other is limited. Limiting awareness 
limits dependencies and makes systems easier to change. Awareness of REP- 
RESENTATION is limited by DATA ABSTRACTION. 


INTERFACE The primary unit of design: Separately compiled syntax that specifies 
whatever properties of an ABSTRACTION are needed to get CLIENT code to 
typecheck. In Molecule, an interface is a MODULE TYPE, which gives names 
and types of the exported operations, plus the types of any nested modules. 
“Interface” is also used to mean a complete API. 


INVARIANT A REPRESENTATION INVARIANT or a LOOP INVARIANT. 


LOOP INVARIANT A property of program state—typically the states of program 
variables and of mutable abstractions—that is true on every iteration of a 
loop. The loop’s body guarantees that if the invariant holds at the begin- 
ning of the body’s execution, the invariant continues to hold at the end of the 
body’s execution. The guarantee can rely on the truth of the loop’s guard. 


MODULE The primary unit of implementation: A container that can ENCAPSULATE 
auxiliary definitions and knowledge of REPRESENTATION, hiding them from 
CLIENT code. 


MODULE TYPE The formal construct that describes an INTERFACE in Molecule or 
OCaml. Analogous constructs in other languages include Java interfaces, 
Modula definition modules, Ada package specifications, and Standard ML 
signatures. 


OBJECT-ORIENTATION A form of DATA ABSTRACTION that operates by bundling op- 
erations with shared state, which is usually mutable (Chapter 10). 


RELY-GUARANTEE REASONING A method of ensuring that a REPRESENTATION IN- 
VARIANT holds. Each operation relies on the property that when the opera- 
tion starts, the invariant holds true of every value of the type. And each op- 
eration guarantees that on exit from the operation, the property holds once 
again. But during the execution of an operation, a representation invariant 
may be temporarily invalidated. 


REPRESENTATION How an ABSTRACTION is realized or represented on a computer. 
In Molecule, as well as in other statically typed languages, a representation 
is specified by a type. A representation may be constrained by a REPRESEN- 
TATION INVARIANT. 


REPRESENTATION INVARIANT A property that is true of the REPRESENTATION of ev- 
ery value of an abstract type. The representation invariant refers to proper- 
ties that are not inherent in the representation but that must be guaranteed 
by the operations that have access to the representation. One example is 
that in a heap, the smallest element is at the root. Another is that in a binary 
search tree, smaller elements are in the left subtree and larger elements are 
in the right subtree. A third example is that when a list is used to represent 
a set, the list contains no duplicate elements. Some representations satisfy 
only trivial invariants, but in most interesting implementations, a represen- 
tation invariant is needed to make the code work. 


SUBTYPING A relation 7 <: 7’ which says that any MODULE of type 7 also has 
type 7’—and therefore can be used wherever a module of type 7’ is ex- 
pected. A programming language may also offer a subtype relation on the 
types of expressions. 


9.11.2 Further reading 


Data abstraction is a form of information hiding, for which best practices were de- 
veloped in the 1970s. Parnas (1972) argues that an effective module hides a de- 
sign decision that is likely to change. Such decisions include input formats, out- 
put formats, and algorithms, as well as the decisions emphasized in this chapter: 
the representations of abstractions. Parnas is sometimes paraphrased as saying 
“every module hides a secret.” Wirth (1971) describes top-down development of 
programs by “stepwise refinement” of high-level specifications into working code. 
He emphasizes that decisions about representation should be delayed as long as 
possible (and thereby hidden from one another). Dahl and Hoare (1972) say that 
“good decomposition means that each component may be programmed indepen- 
dently and revised with no, or reasonably few, implications for the rest of the sys- 
tem.” They argue for a language mechanism based on the objects and classes of the 
Simula 67 programming language; the realization of those ideas in Smalltalk is the 
subject of Chapter 10 of this book. 
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The implementation of an abstract data type can be proved correct using a 
method developed by Hoare (1972). Hoare’s paper introduces the ideas of abstrac- 
tion function and representation invariant, and it argues that the method is essen- 
tial for succinct specifications. If you like math with your code, read it. 

Languages that support abstract data types owe a great deal to CLU. CLU’s ini- 
tial ideas are described by Liskov and Zilles (1974). At that point compile-time type 
checking was just a glimmer on the horizon; the paper emphasizes a deep philo- 
sophical difference between CLU and its predecessor Simula 67—Simula 67 was de- 
signed to expose details of representation, and CLU was designed to hide them. 
A fully developed CLU, complete with compile-time type checking, is described by 
Liskov et al. (1977). The context in which CLU was developed—including the state 
of programming languages before CLU, the connections between CLU and pro- 
gramming methodology, the major principles underlying CLU’s design, and CLU’s 
history—is the subject of a later retrospective (Liskov 1996). And if you are inter- 
ested in an innovative aspect of the implementation, CLU’s exception mechanism 
is described in a more technical paper (Liskov and Snyder 1979). 

Beyond CLU, data abstraction plays an important or even central role in Sim- 
ula 67 (Dahl and Hoare 1972; Birtwistle et al. 1973), Alphard (Wulf, London, and 
Shaw 1976), Modula-2 (Wirth 1982), and Ada. Data abstraction can also be achieved 
using lambda in Scheme, as described by Abelson and Sussman (1985, Chapter 2). 

Abstract data types work very well for data structures; some classic, well- 
engineered examples are presented by Hanson (1996). Hanson’s implementations 
are written in C, so he’s working with stone knives and bearskins, but the results 
are both informative and useful. For more depth in the use of abstract types, and 
to delve into the relationship between software development and software speci- 
fication, consult the excellent book on programming by Liskov and Guttag (1986). 
And for an example of pushing generic modules beyond reasonable bounds, I rec- 
ommend my own work on building a type-safe, separately compiled, extensible 
interpreter (Ramsey 2005). 

Modules and modular type checking are beautifully explained by Leroy (1994), 
who opens with two pages that explain what we ought to expect from modules and 
interfaces, and why. I cannot recommend this work highly enough. The techni- 
cal part of the paper is equally strong, showing how to accommodate a mix of 
abstract and exposed types in one interface; this problem was solved indepen- 
dently by Harper and Lillibridge (1994). Leroy (2000) follows up with a longer paper 
that implements his ideas in a way that enables a compiler or interpreter to easily 
add modules to an existing language. This work directly inspired Molecule’s type 
system—Molecule’s module layer includes just one feature not taken from Leroy: 
the intersection type, as proposed by Ramsey, Fisher, and Govereau (2005). 

Modules are not normally recursive or mutually recursive, and yet much ink 
and even more thought have been expended on making them so. This work has 
yet to find its way into wide use, but my favorite proposal replaces “modules” with 
“units”; a “unit” is a syntactic capsule that puts imports and exports on equal foot- 
ing. Units are linked into larger units by a separate linking language (Flatt and 
Felleisen 1998). 

Modules are often viewed as competing with classes. In a talk by Leroy (1999), 
the two are compared from both theoretical and practical perspectives. Leroy ar- 
gues that modules are most effective in situations where the set of kinds of things 
(data) is likely to remain stable, but the set of operations performed on things is 
fluid. Classes are most effective in situations where the set of operations performed 
on things is stable, but the set of kinds of things is fluid. In a more technical 
comparison, Cook (2009) focuses on fundamental semantic differences between 


Table 9.24: Synopsis of all the exercises, with most relevant sections 


Exercises Section Notes 


land 2 9.2 “Finger exercises” on writing client code using qualified 
names: simple client functions of the IntArray module, 
comparable to what is in Section 9.2. 


3to5 9.3 Opportunities to modify an existing abstraction 
(the 2Dpoint abstraction). 
6 9.4 Changing representation without affecting client code. 
7 and 8 9.4, 9.5 Defining simple abstractions from scratch. 
9 to 13 9.6.1, 9.6.4 Reasoning about abstractions: abstraction functions, in- 


variants, specification, and proof. 

14to18 9.6 Interface design for common data structures, including 
careful specification of operations. Focus on mutability 
and immutability. A couple of small implementations. 

19to28 9.6 Using module types to express common properties of 
data, like “comparable for equality” or “totally ordered.” 
Interface design, some intersection types, and a touch of 
implementation. 

29to 36 9.6.5, 9.7.1 Reusable data structures using generic modules: lists, 
trees, heaps, and a hash table. Substantial implementa- 
tion. 

37to40 =: 9.6.5 Less demanding applications of generic modules: algo- 
rithms like sorting and tree traversal. 

41to45 9.6.1 Performance and cost analysis, building primarily on the 
generic-module exercises. Experimental work and sub- 
stantial implementation. 

46to50 9.7 Operations that inspect representations of multiple argu- 
ments: linear-time set union, followed by increasingly 
ambitious forms of arithmetic, culminating in arbitrary- 
precision signed-integer arithmetic. 

51to55 9.8 Extensions to Molecule’s type system. 


abstract data types and objects and on the relationship between them. Cook also 
discusses how both mechanisms are used in Java, Haskell, and Smalltalk. 

In Haskell, names are overloaded using the type classes proposed by Wadler 
and Blott (1989). Depth in the underlying theory is provided by Jones (1993). Type 
classes are related to modules and module types by Dreyer et al. (2007). And they 
are very cleverly applied by Claessen and Hughes (2000). 

Syntactic forms raise and handle are not actually very good at expressing the 
ways we usually use exceptions. Fora lovely alternative, see the proposal by Benton 
and Kennedy (2001). 


9.12 EXERCISES 


Exercises are arranged mostly by the skill they call on (Table 9.24). Some of my 
favorites, from least difficult to most difficult, are as follows: 


* A circularly linked list with constant-time append demonstrates a simple, 
clever use of a mutable representation (Exercise 30). 
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« Ahash table, which is a client of an association list, showcases separation of 
concerns (Exercise 34). 


* True integers, as opposed to machine integers, have unbounded magnitude 
(Exercises 49 and 50). Thanks to Molecule’s operator overloading, they are 
relatively easy to use as a replacement for int. True-integer exercises also 
appear in Chapter 10, to be done in Smalltalk. The version in Molecule 
does somewhat less and is somewhat easier to implement—but it is not easy. 
The exercises illustrate differences between abstract data types and objects. 


* The order invariant of a binary search tree can be stated simply, precisely, 
and formally—but discovering such a statement is surprisingly difficult (Ex- 
ercise 9). 


9.12.1 Retrieval practice and other short questions 


Qn mo 


What kinds of components can a module have? 
What is a qualified name? What are some examples? 


How is it that the = function can be called without qualification, but the new 
function has to be called by a qualified name? 


What is a client? 
By what syntactic form is a generic module instantiated? 
In Molecule, how do we write the type of an array of Booleans? 


When a case expression matches on a pattern like (XY x y), what kind of thing 
do x and y stand for? Is this semantics more like the semantics of Scheme or 
more like the semantics of WML? 


What is an abstraction function? What is a representation invariant? 
Pick your favorite data structure and state the representation invariant. 
What’s the domain of an abstraction function? 


What representation invariant enables an array to represent a priority queue 
(that is, a heap)? 


What’s the cost of removing the smallest element from a heap? 
What is a creator? A producer? A mutator? An observer? 


What does an operation’s type tell you about whether it is a creator, producer, 
mutator, or observer? 


Just by analyzing its module type, how can you tell the difference between a 
mutable abstraction and an immutable abstraction? 


When you want to reveal the representation of the elem type in an ARRAY ab- 
straction, what keyword do you use to write the module type? 


If the representation of a natural number is changed from a list of digits to 
an array of digits, can client code tell the difference? If so, how? If not, what 
prevents it? 


How is the judgment E' + 7 ~» 7’ pronounced, and what does it do? 


If T is a subtype of J’, can 7 have fewer components than 7’? How about 
more? 


What subset relation corresponds to the subtype relation? 


What is an intersection type? What subtypes does an intersection type have? 


9.12.2 Using abstractions; programming with qualified names 


1. Integer-array operations. Study the implementation of the smallest-int func- 
tion in chunk 530c, then implement these operations on integer arrays: 


(a) Define a function index-of-smallest which finds the index of the 
smallest element in an array of integers. 


(b) Define a function smallest-to-front that moves an array’s smallest 
element to the front, without changing the order of other elements. 


(c) Define a function partition that finds an array’s kth smallest element 
and partitions the array around it. The function should permute the ar- 
ray’s elements and should leave it with this postcondition (for an array 
of size N): 


ali] [k], for each 7 in the range 0 <i < k, 


<a 
alk] < aly], for each j in the rangek < j < N. 
(This function resembles the partition step in Tony Hoare’s Quicksort 


algorithm, and you may want to implement it recursively.) 


2. Iteration. Because Molecule’s core layer is not polymorphic, a function like 
foldr is not terribly useful. The monomorphism of the core layer militates 
toward a function like zScheme’s app, which applies a function to every ele- 
ment of a list (for side effects). 


(a) Define a similar function foreach, which takes a function of type 
(int -> unit) and applies it to every element of an integer array. 


(b) Use foreach to compute the sum of elements in an integer array. 


9.12.3 Changing existing abstractions 


3. New operation: clockwise rotation. Extend the 2Dpoint module with a rotate- 
operation, which rotates a point 90 degrees clockwise. 


4. New operations: equality and inequality. Add operations = and != to module 
2Dpoint. Seal your module with this module type: 


(allof 2DPOINT (exports [abstype t] 
[= =: (t t -> bool)] 
[!= : (t t -> bool)])) 


5. Change of abstraction. In the 2Dpoint example of Section 9.3, function 
quadrant returns a value of type sym, but only four quadrants are possible 
(chunk 534). Alter the module so that the limitation of four quadrants is re- 
flected in the types. 


(a) Change the 2DPOINT module type to include an abstract type quadrant 
and four values of that type, with names UPPER-LEFT, UPPER-RIGHT, and 
so on. (Because these names begin with uppercase letters, they must be 
value constructors.) Replace operation quadrant with a new operation 
get-quadrant of type (t -> quadrant). 


(b) Change the implementation of the 2Dpoint module to conform to the 
new interface. To define type quadrant and its value constructors, use 
a data definition. 


$9.12 
Exercises 


591 


Molecule, abstract 
data types, and 
modules 


592 


9.12.4 Change of representation 


6. Quadrant-magnitude points. In the 2Dpoint example of Section 9.3, client 


code can’t depend on your representation, which leaves you free to change it. 
As a contrived example, change the representation of a 2Dpoint to use only 
nonnegative integers in what I call “quadrant-magnitude” representation. 
This representation is analogous to the sign-magnitude representation used 
by floating-point hardware. 


Change the representation used in 2Dpoint so that a point is represented by 
the result of applying a value constructor to three values: 


* The magnitude x-mag of the x coordinate 
* The magnitude y-mag of the y coordinate 


* The quadrant in which the point lies 


Represent a quadrant in whatever way you like; a small integer will do, but 
you might prefer a symbol or the constructed data of Exercise 5. 


(a) Define an internal invariant function that expresses all the invariants 
of your representation. At minimum, magnitudes x-mag and y-mag 
must be nonnegative. 


(b) The representation stands for that unique point that is located an ab- 
solute distance of x-mag from the y axis, y-mag from the x axis, and 
that is located in the given quadrant. Make this idea precise by defin- 
ing an abstraction function that maps your representation to a pair of 
Cartesian coordinates (x, y). The abstraction function is to be applied 
only to representations that satisfy the invariant; if applied to any other 
representation, it can fail, or it can even give wrong answers. 


(c) Update the operations so they work correctly with your new represen- 
tation. When you finish, the new version should be observationally 
equivalent to the original: it should be impossible for any program to 
tell which version of 2Dpoint it is using. Take special care with points 
whose x or y magnitudes are zero. 


9.12.5 New, simple abstractions 


7. User-interface window. In the world of graphical user interfaces, a window 


is a rectangle in the plane whose sides are parallel to the x and y coordinate 
axes. 


(a) Using your preferred abstraction for 2-dimensional points, define a 
Window module that supports the operations shown in Figure 9.25 on 
the next page. 


(b) Make the abstraction mutable, and add two mutators: +x, which shifts 
the window in a positive x direction, and +y, which shifts the window 
in a positive y direction. 


8. Complex numbers. A complex-number abstraction should export functions 


+, -, *, /, negated, =, !=, and print. In addition, it should export function 
new, which creates a complex number given its (integer) real and imaginary 
parts, and functions re and im, which observe the real and imaginary parts 
of a complex number. 


Creator 


new Is given opposite corners (either upper-left/lower- 
right or lower-left/upper-right) and returns a new 
window with those corners. 


Observers 


get-1l, get-ur Returns a two-dimensional point that represents ei- 
ther the lower-left or the upper-right corner of a 
given window. 


intersect? Tells if two windows overlap. 


Producer 


intersection Is given two windows that overlap, and returns anew 
window that represents the overlapping region. 


Figure 9.25: Operations on user-interface windows (Exercise 7) 


An integer complex number can be represented by constructed data contain- 
ing its real and imaginary parts: 


(data t [C : (int int -> t)]) 


This representation need not satisfy any invariants; all pairs of real and imag- 
inary parts are meaningful. 


Using this representation, define a module Complex that implements integer 
complex numbers. 


9.12.6 Abstraction functions, invariants, specification, and proof 


Assuming types key and value are defined, a binary search tree can be represented 
as constructed data of type bst: 
593. (transcript 530b) += 1570 598> 
-> (data bst [EMPTY : bst] [NODE : (bst key value bst -> bst)]) 
bst :: * 
EMPTY : bst 
NODE : (bst key value bst -> bst) 


Use this representation in Exercises 9 and 32. 


9. Order invariant ona binary search tree. Algebraic data type bst defines a binary 
tree in which each node carries two values, one of type key and one of type 
value. But not every value of this type is a binary search tree: a search tree 
must obey an order invariant. 


(a) Using the inductive structure of binary trees, write a proof system for 
the judgment “tree T satisfies the order invariant.” Take advantage of 
nondeterminism. 


(b) Using your proof system, define a recursive function order-invariant? 


that checks if a value of type bst tree satisfies the order invariant. 


Hint: As in many proofs by induction, it helps to strengthen the induction 
hypothesis. In your proof system, find another, stronger judgment that is 
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easier to prove inductively, and then add a rule that uses the stronger judg- 
ment to prove the order invariant. In your code, define a recursive function 
that checks something stronger than your order invariant, and check the or- 
der invariant by calling that function. 


10. Priority queue as a sorted list. Section 9.6.4 describes a priority queue as a bag 
of values. But a priority queue can also be specified as a sorted list of values. 


Molecule, abstract Using sorted lists as the abstraction, 


data types, and 
modules (a) Write algebraic laws to specify the abstraction function for a represen- 
tation of type (@m ArrayList Elem) .t, as in Section 9.6.5. 


594 : ‘ : f : 
(b) Write algebraic laws to specify the abstraction function for a represen- 


tation as a binary tree. Use the representation given by the type t in my 
implementation of leftist heaps (chunk 556a). 


(c) Write algebraic laws to specify the insert, empty?, and delete-min 
operations on the immutable abstraction described by module type 
IMMUTABLE-PQ (chunk 555a). 


The next three exercises build on the discussion of arithmetic in Appendix B. 


11. Specifications for natural-number arithmetic. Using the representation of a nat- 
ural number as a list, complete the mathematical development for addition 
and subtraction of natural numbers, from Appendix B (page S13): 


(a) Give equations for computing X + c, where X is a natural number and 
cis acarry bit. 


(b) Give equations for computing X — 1, where X is a natural number. 


12. Algorithmic invariants of addition. Prove that when large natural numbers 
X and Y are added, the following invariants hold: 


(a) Every carry bit c; is either 0 or 1. 
(b) Every z; isin the range 0 < z; < b. 


Also prove that addition is correct, that is 
(c) Using equational reasoning, prove that 


(Eas) o(Dee) (Deo) 


a 


13. Proof of correctness of short division. Using the definitions of X, Q, andr from 
Table B.2 in Appendix B, prove that 


Q-d+r=X. 


Use equational reasoning. 


9.12.7 Design, specification, and mutability 
14. Interfaces for sets. 


(a) Define a module type ISET which describes immutable sets. It should 
export types t and elem, and it should export values emptyset, member?, 
add-element, union, inter, and diff. 


15. 


16. 


17. 


18. 


(b) Define a module type MSET which describes mutable sets. It should ex- 
port types t and elem, and it should export values emptyset, member?, 
and add-element, as well as functions that compute union, intersec- 
tion, and difference of two sets. Each two-set function should mu- 
tate its first argument, and those functions should be called add-set, 
intersect, and remove-set. 


You may wish to revisit the “third approach” to polymorphism described in 
Chapter 2 (page 134). 


Association lists. Define a module type ALIST for association lists (Sec- 
tion 2.3.8, page 105). It should export types t, key, and value and values 
empty, find, and bind. Using that module type, write two specifications: 


(a) The abstraction represented by an association list is a set of key-value 
pairs in which no key appears more than once. Using the notation 
of this abstraction, as in Section 9.6.2, write specifications for empty, 
find, and bind. Notate each key-value pair in the form x +> v. 


(b) Using algebraic laws, as in Section 9.6.3, relate the empty, find, and 
bind operations. You might want to revisit the algebraic laws for sets 
(page 548) or laws in general (Section 2.5, page 110). 


Specification for removal from association lists. Add a remove operation to your 
module type for association lists (Exercise 15). The operation could work in 
either of two ways: 


(a) Calling (remove k ps) could return an association list that has no bind- 
ing for k. In other words, (remove k ps) could remove all bindings 
for k. Write algebraic laws for this version of remove. 


(b) Calling (remove k ps) could remove only the most recent binding for k. 
(This is how association lists and hash tables work in OCaml.) This ver- 
sion of remove cannot be specified using the abstraction ofa set of key- 
value pairs as in Exercise 15a, but it is easy to specify using algebraic 
laws. Write algebraic laws for this version of remove. 


Mutable association lists. In Molecule, a linked list represented as constructed 
data is mutable. 


(a) Design a mutable association-list abstraction and call the resulting 
module type MUTABLE-ALIST. The module type should export a creator 
new, and bind should be a mutator, not a producer. 


(b) A mutable association list can implement bind using fewer allocations 
than an immutable one: Even in the worst case, a mutable association 
list should be able to implement bind by allocating at most one new 
record. Including such a version of bind, implement your abstraction. 


Mutability via reference. Module (@m Ref M) exports a type t which is a mu- 
table reference cell containing one value of type M.t. Such a cell is cre- 
ated using function new, read using function !, and written using func- 
tion :=. A reference cell can be used to create a mutable abstraction from 
an immutable one. Demonstrate this trick by defining a generic module 
MutablePQ, which should take one argument of type IMMUTABLE-PQ, and 
which, when instantiated, should have type MUTABLE-PQ. (This trick provides 
a mutable abstraction without providing the cost benefit usually associated 
with mutable abstractions.) 


$9.12 
Exercises 


595 


Molecule, abstract 
data types, and 
modules 


596 


9.12.8 Design with module types 


By intersecting module types using allof, many specifications can be written 
compositionally—common properties of abstractions can be specified using mod- 
ule types, then combined using allof. In the exercises below, you define several 
such module types. The exercises are inspired by the standard type classes in the 
programming language Haskell. (Type classes are another way, related to modules 
and module types, of describing an abstraction.) In most of the exercises, module 
types can be verified using a check-module-type unit test. 


19. 


20. 


21. 


22. 


23. 


24. 


25. 


26. 


27. 


Equality. Define a module type EQ, which specifies an abstraction whose val- 
ues of type t are comparable for equality and inequality. Verify that built-in 
modules Int, Bool, Sym, and Char have module type EQ. 


Total order via relational operators. Define a module type ORD, which speci- 
fies an abstraction whose values of type t are totally ordered, supporting the 
classic four inequality operators. Your definition of ORD should refer to EQ. 
Verify that primitive module Int has module type ORD. 


Total order via comparison function. Define a module type COMPARE, which 
specifies an abstraction whose values of type t can be compared using a 
compare function, which returns a value of type Order.t. 


Interconvertible total orders. Convert between order abstractions: 


(a) Define a generic module MkCompare, which takes as a parameter a mod- 
ule that has both type ORD and type EQ; an instance of MkCompare should 
have module type COMPARE, operating on the type t from its parameter. 


(b) Define a generic module MkOrd, which takes as a parameter a module 
of type COMPARE. An instance should have both type ORD and type EQ, 
operating on the type t from MkOrd’s parameter. 


Numbers. Define a module type NUM, which specifies an abstraction that sup- 
ports addition, subtraction, negation, multiplication, and division, plus a 
conversion function of-int, which takes an argument of type Int.t and re- 
turns a value of the abstraction. Verify that module Int has module type NUM. 


Printability. Define a module type PRINT, which specifies an abstraction that 
exports functions print and print1n. Verify that modules Int, Sym, and so 
on have module type PRINT. 


Collection. Define a module type COLLECTION, which should describe a mu- 
table collection of elements. It should export types t and elem, plus three 
operations: 


¢ Function add should add an element to the collection. 


* Function remove-cps should remove an element from the collection, 
or if the element is not present, call a failure continuation. 


* Function app should take a function as an argument and should apply 
that function to every element of the collection. 


Types of module Int. Verify, using a single check-module-type test, that mod- 
ule Int has module types EQ, ORD, NUM, and PRINT. 


Types of module Complex. Verify that the complex-number abstraction from 
Exercise 8 has module types EQ, NUM and PRINT. And use check-type-error 
to verify that it does not have type ORD. 


28. Generic complex numbers via NUM and PRINT. Using an argument module that 
has module types NUM and PRINT, define a generic module MkComplex, which 
should be a generic version of the complex-number module described in Ex- 
ercise 8. 


9.12.9 Data structures as generic modules 


Classic data structures—of the kind that are agnostic to the data they structure—are 
perfect candidates for generic modules. While comparable to the core-layer poly- 
morphism used to implement sets in zScheme and to the explicit polymorphism of 
Typed pScheme, generic modules make polymorphism easier to use in two ways: 
First, a generic module can depend on an operation as easily as it can depend on 
a type. Second, instantiating a generic module specializes a whole group of opera- 
tions and types at once. These benefits are demonstrated in the exercises below. 


29. Immutable list. A module type for Scheme-like lists might look like this: 


597. (list.mcl 597) = 
(module-type LIST 
(exports 

[abstype elem] 
[abstype t] 
[empty : t] 
[null? : (t -> bool)] 
[cons : (elem t -> t)] 


[car : (t -> elem)] 

[edr : (t -> t)] 

[app : (Celem -> unit) t -> unit)] 
)) 


Implement a generic module List that takes one parameter, a module Elem, 
and returns a module that implements LIST and also has the following mod- 
ule type: 


(exports [type elem Elem.t]) 


30. Mutable list. Design and implement two variations of mutable list: 


(a) A simple variation exposes the representation: client code can mutate 
any car or cdr. This variation corresponds to a “linked list” that is often 
taught to beginning programmers. 


(b) Amore sophisticated variation can provide some abstraction and a rep- 
resentation invariant. Design and implement a mutable list abstraction 
in which the representation points to the last element of a circularly 
linked list. For the representation, you can use your solution to part (a). 
Such a representation enables you to implement a variety of observers 
and mutators in constant space and time: 


¢ Find first element or last element. 

* Remove first element or last element. 

« Add element at head or tail. 

+ Append two lists, mutating both (the first is left with the results of 
the append and the second is left empty). 


This representation is used to implement the List class that is built in 
to wSmalltalk (Chapter 10). 
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31. 


32. 


33. 


34. 


Immutable association list. Using the interface from Exercise 15, implement 
an immutable association list Alist with exported values empty, find, and 
bind. Make it generic, taking key and value modules as parameters. 


Binary search tree. Exercise 15 defines the interface not just for an association 
list, but for any immutable finite map. Implement this abstraction, just as in 
the previous exercise, but as the representation, use the binary search tree 
bst defined in chunk 593. 


Leftist heap. Finish the implementation of the leftist heap whose merge oper- 
ation is given in Section 9.7.1 (page 555). That is, implement operations new, 
empty?, insert, and delete-min. Do not write any new recursive functions— 
any operation that involves more than one node should call merge. 


Hash table. A generic hash table might have this module type: 
598. (transcript 530b) += 1593 599a> 
-> (module-type GENERIC-HASH 
({Key : (exports [abstype t] 
[hash : (t -> int)] 
[= : (t t -> bool)])] 
[Value : (exports [abstype t])] 
--m-> 
(exports 
[abstype t] 


[abstype maybe-value] ; result of lookup 
[Not-Found : maybe-value] 
[Found : (Value.t -> maybe-value) ] 


[new : ( -> t)] 

[insert : (Key.t Value.t t -> unit)] 

[delete : (Key.t t -> unit)] 

[lookup : (Key.t t -> maybe-value)]))) 
module type GENERIC-HASH = ... 


Exported type t is a mutable finite map. 


A simple hash table can keep an array of buckets, where a bucket holds an as- 
sociation list mapping keys to values. Every key on the list must hash to that 
bucket. To support dynamic growth, I recommend augmenting a buckets 
array with an integer population and an integer grow-at, with these invari- 
ants: 


* Ifa key-value pair (k, v) is stored in the hash table, it is stored in the 
association list stored in buckets|i], where i = (Key.hash k) mod n, 
where n is the size of buckets. 


* The total number of key-value pairs stored in the hash table is equal to 
population. 


* The value of population is less than the value of grow-at. 


¢ The number of buckets 7 is at least 1.3 times the value of grow-at. 


To maintain these invariants as key-value pairs are added, the hash table has 
to grow. In particular, it has to grow whenever an insert operation makes 
population equal to grow-at. Growth is easy to get wrong; I have used a 
production system in which the hash table grew too slowly, the association 
lists got too long, and eventually operations that should have taken constant 


35. 


time took linear time instead. For ideas about monitoring the internal state 
of the hash table, see Exercise 35. 


I recommend initializing a hash table with n = 17 buckets, then growing n 

using the following sequence of prime numbers: 

599a. (transcript 530b) += 1598 

-> (val prime-sizes 
"(17 23 31 41 59 79 103 137 179 233 307 401 523 683 907 1181 

1543 2011 2617 3407 4441 5779 7517 9781 12721 16547 21517 
27983 36383 47303 61507 79967 103963 135173 175727 228451 
296987 386093 501931 652541 848321 1102823 1433681 1863787 
2422939 3149821 4094791 5323229 6920201 8996303 11695231 
15203803 19764947 25694447 33402793) ) 


A prime size uses of all the bits in the hash value effectively, and each of these 
primes is at least 1.3 times larger than the one the precedes it. 


Using these guidelines, implement a generic hash table Hash that grows as 
needed, on demand. Keep your code simple by relying on the association- 
list interface to find a key in a given bucket. 


Hash-table diagnosis. A hash table is efficient only when its lists are short. But 
if we want to confirm efficiency experimentally, the lengths of the lists are 
hidden by the abstraction! To study a hash table’s performance, we have to 
open up the abstraction barrier. In this exercise, I recommend exposing a 
histogram of the lengths. For example, the histogram below depicts the state 
of a hash table built by inserting the names of 10 Turing laureates into an 
empty hash table: 


Q | RRR REE 
1 [eK 
2 |**® 


The hash table has 17 buckets in all; 9 are empty, 6 have exactly one element, 
and just 2 buckets have more than one element. The table contains 10 key- 
value pairs and so is about 60% full. The expected cost of a successful lookup 
is determined by the average number of pairs in a nonempty bucket, which 
is 1.25. 


The next insertion brings the population to 11, triggering the grow operation. 
The number of buckets increases to 23: 


Q | RRRRRRRRRRR ARK 
1 [RR 
2 [*® 


Histograms can be obtained by extending the hash-table interface with an 
operation histogram of type (t -> Histogram.t), where module Histogram 
implements this interface: 
599b. (histogram.mcl 599b) = 

(module-type HISTOGRAM 


[exports 
[abstype t] ;; finite map int -> int (key to count) 
[new ee in oak | ; every int maps to zero 
[inc : (int t -> unit)] ; increment count of given int 
[inc-by : (int int t -> unit )] ; increment by more than 1 
[count-of : (int t -> int)] ; fetch count of given int 
[visualize : (t -> unit)]]) ; visualize the whole thing 


Source code for Histogram can be found in the Supplement. 
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Add the histogram operation to your hash table from the previous exercise, 
and use it to diagnose performance. 


36. Mutable and immutable sets. Using the data structure and invariants of your 
choice, implement the set abstractions from Exercise 14. 


(a) Implement the mutable set abstraction MSET. 


Molecule, abstract (b) Implement the immutable set abstraction ISET. 
data types, and 
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Like a polymorphic data structure, a polymorphic algorithm can be written as a 
generic module. 


37. Generic array functions. Revisit Exercise 1, and reimplement its functions to 
work generically on any array whose elements are totally ordered. (If you 
have completed Exercise 20, use module type ORD.) 


38. Abstract tree traversals. Define a generic module Traversals, which should 
export functions for traversing binary trees. It should take one parameter 
Tree of this type: 

600. (exercises.mcl 600) = 602 > 
(module-type BINARY-TREE 
(exports [abstype t] 
[abstype value] 


[empty? : (t -> bool)] ; observer 

[the-value : (t -> value)] ; observe only nonempty tree 
[left : (t -> t)] ; subtree of nonempty tree 
[right ¢ (t —> t)])) ; subtree of nonempty tree 


Module Traversals should export the following functions, each of which 
takes an argument of type Tree. t and another of type (Tree. value —> unit): 


(a) Function preorder should implement a preorder traversal. 
(b) Function inorder should implement an inorder traversal. 
(c) Function postorder should implement a postorder traversal. 
(d) Function levelorder should implement a level-order traversal. 
39. Sorting. Define a generic module Sort that takes as parameters an ARRAY 
abstraction whose elements satisfy the ORD module type from Exercise 20. 


The module should export one function sort, which sorts an array in place 
(by mutating it). 


40. Heapsort. Define a generic module Heapsort that takes as parameters an 
Elem abstraction and exports a function sort, which sorts an array of type 
(@m Array Elem) .t in place. Sort the array by inserting every element into a 
priority queue, then using the priority queue to order the elements. 


9.12.11 Performance and cost models 


41. Comparing heap performance. The chapter describes two representations of a 
heap: a mutable array representation and an immutable leftist heap. 


(a) For various sizes of array, measure the cost of building a mutable heap 
from an array in the style of the Heapsort module (Exercise 40), which 
calls insert repeatedly. 


(b) For various sizes of array, measure the cost of building a leftist heap 
from an array, in a different style, by calling merge repeatedly: start 
by making one-element heaps, then merge pairs to make two-element 
heaps, then merge pairs to make four-element heaps, and so on until 
you have a single heap. This algorithm can be implemented fairly easily 
by using an ArrayList as a queue. 


(c) How large an array do you need before the repeated-merge algorithm 
beats the repeated-insert algorithm? §9.12 


(d) Revisit Exercise 40 (Heapsort), and implement two versions: one that Exercises 


uses the priority queue based on a mutable array, and one that uses 601 
the priority queue based on an immutable leftist heap. Measure which 
heap provides a faster sort as the array to be sorted gets large. 


42. Cost model of a hash table. An abstraction has both a semantics and a cost 
model. For a hash table, the cost model includes constant-time insertion. 
Since an insertion can make the hash table grow, the appropriate bound is 
not worst-case cost; it is amortized cost: as N gets large, a sequence of N 
insertions must have a cost proportional to N. 


This aspect of hash-table implementation can be hard to get right. A mis- 
take can change the cost of N insertions to O(N log N) or even O(N?). 
In Exercise 34, all elements are reinserted every time the hash table grows, 
and it grows O(log NV) times in total. But nevertheless, the total work is not 
O(N log N); itis O(N). 


(a) Suppose that at each growth step, N doubles. Some elements will be 
reinserted for the log, Nth time, but half of the elements are rein- 
serted for the first time. Prove that the average number of reinsertions 
is at most 2. 


(b) Now suppose that at each growth step, N increases by a factor of 1.3. 
Prove that the average number of reinsertions is bounded by a constant, 
and find the constant. 


(c) Demonstrate experimentally that as N gets large, the cost of inserting 
N elements into the hash table is proportional to N. A plot of CPU time 
versus NV should resemble a straight line, but because the costs of gar- 
bage collection may vary with N, your plot may have some jitter. 

To make your experiments as painless as possible, I recommend com- 
piling the Molecule interpreter with MLton or some other Standard ML 
compiler that generates native machine code. 


43. Refinements to a hash table. To find a key in a given bucket, the hash table in 
Exercise 34 uses an association list. This convenience keeps the hash-table 
code simple: the hash table manages the array of buckets, and in any bucket, 
it lets the association list search for the right key. But the convenience may 
cost something at run time, especially if comparing keys for equality is ex- 
pensive. A production hash table might include these refinements: 


+ Along with each key-value pair, a production hash table can store the 
hash of each key, so it never needs to be recomputed. 


* In lookup, insert, and delete, a production hash table can avoid com- 
paring keys except when they have the same hash. Hashes are small in- 
tegers and can be compared very quickly, whereas keys might be long 
arrays (strings) or large data structures whose comparison takes much 
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longer. When there are multiple keys in a bucket, saving comparisons 
might matter. 


How and when these refinements actually improve things is an experimental 
question. 


(a) Which do you expect to be faster: the original hash table, or one with 
the refinements? On what grounds? Justify your answer. 


(b) Compared with the size of the Hash module, how much additional code 
do you expect a refined version to require? 


(c) Create anew module RefinedHash that implements the same interface 
as Hash but incorporates the refinements listed above. 


(d) Construct, if you can, a test program that exposes a performance dif- 
ference between the two different implementations of the hash table. 
Explain your results. 


44. Hybrid structures. Hash tables and arrays provide similar abstractions, but 


with different cost models. But why should picking the right cost model be 
up to the poor programmer? In this exercise, you make the computer do the 
work. In the following abstraction, integers can index into a hash table or an 
array, whichever seems better: 


602. (exercises.mcl 600) += <1600 
(module-type HYBRID-ARRAY 
(exports [abstype t] 77 an array 
[abstype elem] ;; one element of the array 
[new Put =p 2] ; creator 
[at : (t int -> elem)] ; observer 


[at-put : (t int elem -> unit)] ; mutator 
[foreach-at : (t (int elem -> unit) -> unit)])) ; observer 


Design and implement a generic module HybridArray, which takes one pa- 
rameter: a module Elem that exports a type t, a value default of type t, 
a hash function, and an = function. An instance should have module type 
HYBRID-ARRAY, and your implementation should have these properties: 


* Function new should return an array that maps every index to the 
default element from the Elem parameter. 


Function foreach-at should apply its function parameter to every non- 
default element in the array, with index. 


The representation should include an array part and a hash part. The 
implementation should identify an interval of integer keys that is dense 
with non-default values; it should store these values in the array part, 
and it should place the remaining key-value pairs in the hash part. 
As an invariant, the implementation might require that the array part 
either be of size 8 or hold at least 70% non-default values. 


This sort of hybrid array provides the best of both worlds, but the imple- 
mentation may occasionally have to migrate keys from the hash table to the 
internal array, or vice versa. 


A design like this is used to implement the table abstraction in the program- 
ming language Lua. 


45. 


Influence of base on natural-number performance. After completing the imple- 
mentation of natural numbers described in Exercise 49, experiment with dif- 
ferent values of the base b: 


(a) Implement large natural numbers using base b = 10. 


(b) Implement large natural numbers using the largest possible base that 
is a power of 10 (so that print can be implemented without implement- 
ing short division). It must be possible to compute (* (- 61) (- b1)) 
without causing arithmetic overflow; to find the largest such b, experi- 
ment with your version of Molecule. 


(c) Create a benchmark that exposes a performance difference between 
these two implementations of large natural numbers. Explain the dif- 
ference. Make your explanation quantitative! 


(d) Implement large natural numbers using the largest possible b, not nec- 
essarily a power of 10, such that (* (- b 1) (- 6 1)) can be computed 
without causing arithmetic overflow. In order to print your natural 
numbers, you will have to implement short division. 


(e) Create a benchmark that exposes a performance difference between 
the bases used in parts (c) and (d). Under what circumstances does the 
performance improvement of part (d) justify the effort of implementing 
short division? 


(f) Change b to be as small as possible without breaking the code. Explain 
why this value of b can be expected to work, and measure the cost in 
performance relative to a more efficient b. 


9.12.12 Inspecting multiple representations 


Compared with objects, abstract data types offer one great strength: a function can 
easily inspect the representations of multiple arguments. This strength is demon- 
strated in the exercises below, starting with a simple set-union problem and con- 
tinuing through progressively more ambitious forms of arithmetic. 


46. 


47. 


Linear-time set union. Define an integer-set abstraction whose representa- 
tion is a sorted list without duplicates. Use the invariant to implement a 
union operation that takes time proportional to the sum of the lengths of 
the operands. 


Rational-number arithmetic. Design and implement module Fraction, which 
does arithmetic on rational numbers. Rational numbers should be im- 
mutable, and at minimum, your module should implement operations new 
(to create a rational number from an integer), +, -, *, /, negated, =, !=, <, 
<=, >, >=, and print. A rational number should be printed in lowest terms; 
that is, the greatest common divisor of the numerator and denominator 
should be 1. 


Reduce code bloat by keeping in mind such algebraic laws as (x > y) = 
(y <2)and (x <y) =—(x > y). 

For some ideas, look to the implementation of class Fraction in Chapter 10 
(page 664). 
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48. 


Floating-point arithmetic. Design and implement module Float, which does 
arithmetic on floating-point numbers. Your module should implement op- 
erations new (to create a floating-point number from an integer), +, -, *, 
/, negated, =, !=, <, <=, >, >=, and print. Floating-point numbers are im- 
mutable. 


A floating-point number approximates a real number by a rational number 
of the form m-b°, where mis the mantissa, bis the base, and e is the exponent. 
For ease of printing, I recommend using b = 10, and to prevent arithmetic 
overflow, I recommend maintaining the representation invariant —32767 < 


m < 32767. 


For some ideas, look to the implementation of class Float in Appendix U 
(page S567). The class uses these tricks: 


+ During computation, the invariant that restricts the size of m might be 
violated temporarily. The invariant is restored in this way: While m 
is too big, divide m by b and add 1 to e. Each division may lose preci- 
sion, introducing floating-point rounding error, but restoring the invari- 
ant protects against future overflow. 


* The abstraction is immutable, but an implementation may benefit from 
using a mutable representation—as long as no mutation has an effect 
that can be observed by client code. 


* Two floating-point numbers can be added if they have equal exponents: 
my, + © + m2 + b© = (mj, + mg) - b&. To make exponents equal, find 
the number with the smaller exponent, and keep dividing m by b and 
adding 1 to e until the exponents are equal. Then add the mantissas, 
and if m1 + mz violates the representation invariant, restore it. 


+ Any two floating-point numbers can be multiplied using the algebraic 
law my - b& + m2 +b = (m,-mz)-b%*: multiply the mantissas and 
add the exponents. Andifm -mz violates the representation invariant, 
restore it. 


* Not every operation has to be implemented from scratch. If you have 
+ and negated, you have -. And for comparisons, x < y if and only if 
y—x>O0. 


49. Arbitrary-precision natural-number arithmetic. Read about natural-number 


arithmetic in Appendix B. Following the guidelines there, design and builda 
module Natural that implements the NATURAL abstraction. Supplement Ap- 
pendix B with this advice: 


* Implement print using short division. To print anonzero number X in 
decimal format, use short division to compute quotient Q = X div 10 
and remainder r = X mod 10. First print Q, then print r. 


+ If you represent a natural number as an array of digits, define a non- 
exported operation digit that will help you pretend that X and Y are 
the same size: asking for a digit beyond the bounds of an array should 
return 0. And you may benefit from using ArrayList, which can grow 
or shrink at need. 


* When testing, bear in mind that check-expect relies on your imple- 
mentation of =, which might have a bug. You might want to extend 
your module with an operation called decimals, which returns an ar- 
ray of decimal digits with the most significant digit first. That array can 


then be given to check-expect, to be compared with an array written 
by hand. 


50. Arbitrary-precision signed-integer arithmetic. Read about signed-integer arith- 


metic in Appendix B. Following the guidelines there, design and implement 
a generic module Bignum that implements large signed integers. This abstrac- 
tion of the integers is not limited by the size of a machine word—a large inte- 
ger can be any integer whose representation fits in your machine’s memory. 
Large integers, like machine integers, are immutable. 


A useful implementation of signed integers will provide everything in the 
INT interface in Appendix B, plus short division, plus a way to create a large 
integer from a small one. 
605a. (bignum.mcl 605a)= 605b > 
(module-type BIGNUM 
(allof 
INT 
(exports 
[abstype t] 
[module [QR : (exports-record-ops pair ([quotient : t] 
[remainder : int]))]] 
[sdiv : (t int -> QR.pair)] 
[of-int : (Int.t -> t)]))) 


Your Bignum module should take a module Natural of type NATURAL as a pa- 
rameter, and it should return a module that implements BIGNUM, like this: 
605b. (bignum.mcl 605a) += <1605a 
(generic-module [Bignum : ([Natural : NATURAL] --m-> BIGNUM) ] 
(implementation of signed integers (left as an exercise)) ) 


To represent the magnitude of an integer, use a value of type Natural. t (Ex- 
ercise 49). To couple the magnitude with a sign, you might choose any of the 
representations suggested in Appendix B. 


Because long division is tiresome, I recommend that your / operation simply 
evaluate an error expression, but if you want to implement long division, 
read Brinch Hansen (1994) or Hanson (1996, Chapters 17 and 18). 


9.12.13 Molecule’s type system 


51. 


52. 


Better overloading. Molecule’s function overloading chooses the most re- 
cently overloaded type whose first argument matches the type of the func- 
tion’s first actual parameter. But Molecule could instead choose a function 
based on the types and number of all the actual parameters. 


(a) Update the function-application rule to make it so. 


(b) Venture into the interpreter and implement your new rule. (The main 
challenge will involve error messages.) 


Principal type of a generic module. When an exporting module is sealed, it is 
checked by confirming that its principal type is a subtype of the (realized) 
module type used to seal it. Perhaps generic modules could be checked the 
same way. Supposing that we extend Molecule with a one-argument generic- 
module form MODULE-LAMBDA(M : 7, ds), write typing rules to give the 
principal type of such a form. 
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55. 


Module-arrow subtyping. Following up on the previous exercise, when both 
subtype and supertype are arrow types, the result part of the subtype must 
provide at least as many components as the supertype’s result is expecting. 
But the argument part works the other way: the subtype must ask for at most 
as much from its argument as the supertype argument is capable of provid- 
ing. This reversal of direction is called contravariance, and it is part of any 
sound type system that supports subtyping with arrow types. Extend the 
rules for the subtyping judgment so that it works on module-arrow types. 


. Contextual type equality. Type equality can be made contextual, with a judg- 


ment of the form E+ 7, ®& 7), which means that under the assumptions 
explicit in environment F, types 7, and 72 are equivalent. 


(a) Write rules for this judgment. 


(b) Implement this judgment. 


For part (b), I wouldn’t try to compute a substitution—I would use a union- 
find algorithm. 


Subtyping in the core layer. In Standard ML or OCaml, subtyping of mod- 
ule types is complicated by the presence of polymorphism in the core 
layer. For example, if a supertype demands a length component of type 
((list int) -> int), that demand could be satisfied by a length definition 
with the more polymorphic type (forall ['a] ((list 'a) -> int)). 


(a) In ML, type 7 is a subtype of 7’ if 7 is “at least as polymorphic” as r’—in 
other words, if 7 is more general than 7’. Write rules for this subtype 
relation on core-layer types. 


(b) Assuming that there is a subtype relation 7 <: 7’ on core-layer types, 
update the rules for subtyping on module types. 
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Smalltalk and object-orientation 


Smalltalk’s design—and existence—is due to the 
insight that everything we can describe can be 
represented by the recursive composition of a single 
kind of behavioral building block that hides its 
combination of state and process inside itself and can 
be dealt with only through the exchange of messages. 


Alan Kay, The Early History of Smalltalk 


Data and operations belong together, and 
most useful program constructs contain both. 


Ole-Johan Dahl and Kristen Nygaard, 
The Development of the SIMULA Languages 


An abstract data type is not the only way to hide the representation of data: a rep- 
resentation can also be hidden in an object. An object is a bundle of operations— 
often called methods—that may share hidden state. An object interacts with other 
objects by sending messages; each message activates a method on the receiving ob- 
ject. An object’s methods can see the representation of the object’s own state, but 
not the representations of the states of other objects. 

Grouping state with methods turns out to be unreasonably powerful. Perhaps 
as a result, object-oriented languages—or more precisely, procedural languages in- 
fused with object-oriented ideas—have been popular since the 1990s. The popular 
languages draw from ideas originally developed in Simula 67, Smalltalk-80, and 
Self, which collectively represent three decades of language design. Simula 67 (Ny- 
gaard and Dahl 1981) introduced objects and classes, which it layered on top of 
Algol 60, a procedural language. Smalltalk-80 simplified Nygaard and Dahl’s de- 
sign by eliminating the underlying procedural language; Smalltalk is purely object- 
oriented. Self (Ungar and Smith 1987) simplified Smalltalk’s design still further, 
eliminating classes. For learning, the best of these languages is Smalltalk: Because 
it is not layered on top of a procedural language, it won't distract you with super- 
fluous features. And because it does have classes, it is easy to relate to such succes- 
sor languages as Objective C, C++, Modula-3, Ruby, Java, Ada 95, and Swift—even 
though most of these successors are actually procedural languages with object- 
oriented features. 

Smalltalk is designed around one idea, simplified as much as possible, and 
pushed to a logical extreme: everything is an object. In Smalltalk-80, every value is 
an object: for example, the number 12 is an object; every class is an object; the pro- 
gram is an object; the compiler is an object; every activation on the call stack is 
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an object; the programming environment is an object; every window is an object; 
and even most parts of the hardware (display, keyboard, mouse) are modeled by 
objects. Furthermore, conditionals and loops are implemented not by evaluating 
special syntactic forms like if and while but by sending continuations to objects. 
While Smalltalk does not treat the interpreter and the hardware as objects, it does 
ensure that every value and class is an object, and it does implement conditionals 
and loops by sending continuations. 


10.1 OBJECT-ORIENTED PROGRAMMING BY EXAMPLE 


In Smalltalk, a computation proceeds as a sequence of actions, each of which typ- 
ically mutates a variable or sends a message to an object. (An action may also allo- 
cate a closure or terminate the execution! of a method.) When a message is sent to 
an object, which is called the receiver, that message is dispatched to a method. Like 
a function in full Scheme, a Smalltalk method binds arguments to formal parame- 
ters, then evaluates a sequence of expressions. The method to which a message is 
dispatched is determined by the class of the object receiving the message. A class 
defines methods, but it also inherits methods from a designated superclass. Anda 
class defines the representation of each of its objects, which are called instances of 
the class. 

While method dispatch and inheritance are important, the heart of object- 
oriented programming is exchanging messages: “You don’t send messages be- 
cause you have objects; you have objects because you send messages” (Metz 2013, 
page 67). In the examples below, messages are exchanged among four sorts of ob- 
jects: 


* Coordinate pairs, which represent locations and which can be added and 
subtracted as vectors 


* Shapes, which can be asked about their locations, moved to given locations, 
and drawn on canvases 


Pictures, which collect shapes 
* Canvases, on which shapes and pictures can be drawn 


The examples below begin by sending messages that draw a picture. 


10.1.1 Objects and messages 


The object that receives a message is called the message’s receiver. On receiving 
a message, an object activates the execution of a method; the method does some 
internal computation and eventually replies with an answer. A method is a bit like a 
function, and an object is a lot like a bundle of functions that share state—typically 
mutable state. But in Smalltalk, unlike a procedural or functional programming 
language, the caller cannot choose what function is called—a caller chooses only 
what message to send. When the message is received, the method that is executed 
is determined by the class of the receiver. 

Syntactically, a message send has three parts: an expression that evaluates to 
the receiver, the name of the message, and zero or more arguments: 


exp 1:= (exp message-name { exp} ) 


1For Smalltalk, I say “execute” instead of “evaluate.” They mean the same thing, but “execute” carries 
connotations of imperative features and mutable state, which are typical of Smalltalk. 


In this syntax, as in Impcore’s function-call syntax “(function-name {exp}) » the 
operation that is intended is named. But the name means something different, and 
it is therefore written in a different place: 


* Ina procedural language like Impcore, the caller determines the code that is 
executed and identifies it by naming the procedure, which is written first. 


§10.1 
* In an object-oriented language like Smalltalk, the caller picks the name of the Object-oriented 
message sent, and a method with that name is eventually executed, but the programming 
receiver determines which one. That’s why the receiver is written first. by example 
* In a functional language like wScheme, the caller doesn’t have to name the 611 


code that is executed, but the semantics and syntax are like procedural se- 
mantics and syntax: the caller determines what function is executed, and 
the function is written first. 


Receiver-first syntax is found not only in Smalltalk but also in C++, Java, JavaScript, 
Ruby, Modula-3, Lua, Swift, and essentially all languages that emphasize object- 
oriented features. Most typically, the receiver is followed by a dot, the name of the 
message, and arguments in parentheses. 

Message sends by themselves are enough to write some interesting computa- 
tions, provided some interesting objects are available to send messages to. To il- 
lustrate, I send messages that draw the picture “Cj _}.” The messages are sent to 
objects that represent classes, shapes, the picture, and a “canvas” on which the pic- 
ture is drawn. To start, I send the new message to the Circle class, which creates a 
circle object. 


61la. (transcript 611a)= 611b> 
-> (use shapes.smt) ; load shape classes defined in this section 
-> (val c (Circle new)) 
<Circle> 


The Circle class, like every Smalltalk class, is also an object, and by default, send- 
ing new to aclass object creates a new instance of that class. The word new does not 
signal a special syntactic form the way it does in Java or C++; it’s a message name 
like any other. 
Next I send new to the Square class, creating a new square: 

611b. (transcript 611a) += <6lla 61lc> 

-> (val s (Square new)) 

<Square> 


By default, a new shape has radius 1 and is located at the coordinate origin. 
So both s and c are initially at the origin—and s needs to be moved to the right of c. 


adjustPoint: to: 
I send two messages: J 


621a 

: : : “ ae Circle 620 
+ Ask circle c for the location of its East “control point. Teac onT ecole 
* Tell square s to adjust its position to put its West control point at that same Square 621b 


location. 


A “control point” is a point on a square in which a shape is inscribed (page 619). 
Control points are labeled with symbols 'North, 'South, and so on. Using control 
points, I tell the square, “adjust yourself to place your West control point at the same 
location as the circle’s East control point”: 
61lc. (transcript 611a) += <611b 612aD 
-> (s adjustPoint:to: 'West (c location: 'East)) 
<Square> 
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Both adjustPoint:to: and location: are message names, also called message selec- 
tors; s and c are receivers; 'West, 'East, and (c location: 'East) are arguments. 
The combination of message name and arguments forms a message. Each message 
name has a number of colons equal to the number of arguments in the message. 
I create a new triangle and adjust it immediately, without first placing it in a 
variable. The adjustPoint:to: message answers the triangle (its receiver).” 
612a. (transcript 611a) += <61lc 612b> 
-> (val t ((Triangle new) adjustPoint:to: 'Southwest (s location: 'East))) 
<Triangle> 


The expression reads almost like pidgin English: “hey new triangle, adjust your 


southwest control point to the location of s’s east point.” 
I now put all three shapes into a picture. 


612b. (transcript 611a) += <612a 612c> 

-> (val pic (Picture empty) ) 

<Picture> 

-> (pic add: c) 

<Picture> 

-> (pic add: s) 

<Picture> 

-> (pic add: t) 

<Picture> 


Message empty is sent to the Picture class, which answers a new object that repre- 
sents an empty picture. Message add: is then sent to that object, pic, with different 
arguments. Each add: message answers the (modified) picture. 

The picture is rendered using a canvas, which is created by sending the new 
message to class TikzCanvas. 
612c. (transcript 611a) += <612b 622b> 

-> (val canvas (TikzCanvas new)) 
<TikzCanvas> 
-> (pic renderUsing: canvas) 
\begingtikzpicture3[x=4pt,y=4pt] 
\draw (0,0)ellipse(1 and 1); 
\draw (3,1)--(1,1)--(1,-1)--(3,-1)--cyele; 
\draw (4,2)--(3,0)--(5,0)--cycle; 
\endgtikzpicturez 
<Picture> 
The arcane output is a program written for the TikZ package of the ETpX typesetting 
system, which produces “CYP.” 

The examples above send new to several class objects, send location: and 
adjustPoint: to: to objects that represent shapes, send empty to the Picture class, 
and send add: and renderUsing: to the resulting instance of Picture. How did I 
know what messages to send? And how do the receiving objects know what to do 
with them? Messages and their associated behaviors are determined by protocols 
and class definitions, which are the subject of the next section. 


10.1.2 Protocols, methods, classes, and inheritance 


In Impcore, we can call any function named in the function environment ¢. 
In Scheme, we can call any function we can compute, even if it has no name. 


Smalltalk uses the verb “to answer” in a nonstandard way. In standard English, when you answer 
something, the thing answered is a request: you might “answer” an email or “answer” your phone. But 
in Smalltalk jargon, “answer” means “to send as the answer.” A method might “answer a new object” 
or “answer a number.” This usage should grate on your ear, but like any other jargon, it soon seems 
normal. 


Answer a new instance of class CoordPair with 
the given arguments as its (x, y) coordinates. 


withX:y: aNumber aNumber 


(a) Class protocol for CoordPair 


x Answer the x coordinate of the receiver. 
y Answer the y coordinate of the receiver. 
* aNumber Answer a new instance of class CoordPair whose (x, y) 


coordinates are the coordinates of the receiver, multiplied by 


the given number. 
+ aCoordPair Answer a new instance of class CoordPair whose (sr, y) 


coordinates are the vector sum of the receiver and the 


argument. 

- aCoordPair Answer anew instance of class CoordPair whose (x, y) 
coordinates are the vector difference of the receiver and the 
argument. 

print Print the receiver in the form (x,y). 


(b) Instance protocol for CoordPair 


Figure 10.1: Protocols for CoordPair 


In Smalltalk, we can send any message that the receiver understands. The mes- 
sage name is not looked up in an environment, as in Impcore, and it does not eval- 
uate to a value, as in Scheme. Instead, it is used by the receiver to determine what 
code should be executed in response to the message, using the dynamic dispatch 
algorithm described in Section 10.3.4 (page 631). 

The messages that an object understands form the object’s protocol. Like a Mole- 
cule interface, a Smalltalk protocol describes an abstraction by saying what we can 
do with it: what messages an object understands, what arguments are sent with 
that message, and how the object responds. 

Our first example protocols (Figure 10.1) are associated with class CoordPair, 
which defines an abstraction of (x,y) coordinate pairs, or equivalently, two- 
dimensional vectors. In the pictures, these pairs represent locations. 


* The first protocol is the class protocol for CoordPair. This protocol specifies 
messages that can be sent to the CoordPair class, which is represented by 
an object named CoordPair. Sending withX:y: to the class results in a new 
object that is an instance of the class. 


* The second protocol is the instance protocol for CoordPair. This protocol 
specifies messages that can be sent to any instance of the class. Sending * 
multiplies the receiving vector by a scalar, while sending + or - does vector 
arithmetic. Sending print prints a textual representation of the instance. 


The methods in the instance protocol are divided into three groups: access 
to coordinates, arithmetic, and printing. In Smalltalk-80, such groups were 
called “message categories,” but today they are just “protocols’—so a class’s 
instance protocol is a collection of smaller protocols. 


The CoordPair abstraction is immutable, as we can tell from its protocol: no mes- 
sage mutates its receiver. In general, messages can be classified using the ideas 
and terminology introduced in Section 2.5.2 (page 111), which are also used to clas- 
sify operations in a Molecule interface. In the class protocol, message withX:y: is 
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a creator. In the instance protocol, messages *, -, and + are producers. The abstrac- 
tion is immutable, so the protocols include no mutators. Messages x, y, and print 


are observers. 


The protocols for a class and its instances are determined by a class definition. 
A class definition associates each message name (the interface) with a method (the 


implementation). In jsSmalltalk, a class definition is written with this syntax: 


def ::= (class class-name 


[subclass-of superclass-name] 
[c ivars { instance-variable-name} 1] 
{ method-definition } ) 


method-definition ::= 


(class-method method-name (formals) [[locals locals]| {exp}) 
| (method method-name (formals) [[locals locals] | { exp}) 


From the top down, 


+ Aclass definition names the new class and identifies its superclass. 


* Aclass definition determines how every instance of the class is represented. 
Except for a few kinds of primitive objects, the representation is a set of 
named variables called instance variables. Each instance variable stands for 
a mutable location, which may contain any object.? The names of a class’s 
instance variables, if any, are listed just after its superclass. And in addition 
to the names listed, an instance inherits instance-variable names from the 
superclass. 


A method definition determines how an instance of the class responds to the 
corresponding message; the message becomes part of the instance protocol. 


* A class-method definition determines how the class itself responds to the 
corresponding message; the message becomes part of the class protocol. 
Both instance methods and class methods may declare local variables. 


Like instance variables, the instance methods and class methods of a superclass 
are inherited by subclasses. 

Our first class definition defines CoordPair, which implements the CoordPair 
protocols (Figure 10.2, on the next page). 


+ Every new class has to have a superclass. Unless there is a reason to choose 
something else, the superclass should be class Object. Class Object defines 
and implements a protocol useful for all objects, including such operations 
as printing, checking for equality, and several others. Class CoordPair in- 
herits this protocol and the corresponding methods, with two exceptions: 
the inherited = and print methods are redefined, or, in object-oriented ter- 
minology, overridden. 


+ An instance of class CoordPair is represented by the instance variables x 
and y. As noted in the comment, both x and y are numbers—this is the rep- 
resentation invariant of the abstraction. 


3In this book, “variable” means the name you look up in an environment to find a mutable location. 
But in the literature on Smalltalk-80, “variable” means the mutable location. Alas, terminology is hard 
to agree on. 


615. (shape classes 615)= 617> 
(class CoordPair 
[subclass-of Object] 
[ivars x y] ; two numbers 777777 Representation, 


(class-method withX:y: (anX aY) 777777 Lnitialization 
((self new) initializeX:andY: anX aY)) 
(method initializeX:andY: (anX aY) ;; private 
(set x anXx) 
(set y aY) 
self) 


(method x () x) 777777 Observation of coordinates 
(method y () y) 


(method = (coordPair) 777777. Equivalence 


(left-round print) (x print) (', print) (y print) (right-round print)) 


(method * (k) 777477 Scaling and translation 
(CoordPair withX:y: (x * k) (y * k))) 


(method + (coordPair) 

(CoordPair withX:y: (x + (coordPair x)) (y + (coordPair y)))) 
(method - (coordPair) 

(CoordPair withX:y: (x - (coordPair x)) (y - (coordPair y)))) 


Figure 10.2: Definition of class CoordPair 


The method definitions can be understood only once we understand the meanings 
of the names they use. In Smalltalk, unlike in Molecule, access to information is 
controlled by controlling the environment in which each method body is evaluated; 
a method can access only what it can name. 

Every method has access to global variables and to its named parameters, as in 
Scheme or Molecule, plus any local variables that might be declared with locals. 
And every method can use the special name self, which refers to the object re- 
ceiving the message.* (The name self cannot be assigned to; a method’s receiver 
is mutated by mutating its instance variables.) Finally, every method has access 
to the instance variables of the receiver, which are referred to directly by name. 
For example, in Figure 10.2, method initializeX:andY: mentions names x and y. 

Unlike a function in a Molecule module, which has access to the representa- 
tion of every argument whose type is defined in that module, a Smalltalk method 
has access only to the representation of the receiver; arguments are encapsulated. 
A method has no access to the representation of any argument; all it can do with 
an argument is send messages to it. 

In Figure 10.2, the method definitions of class CoordPair are organized into 
three groups. 


4Because the receiver does not appear on the list of a method's formal parameters, referring to it re- 
quires a special name. Some object-oriented languages use this instead of self; others provide syntax 
by which the programmer can choose a name. 
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* Instances of class CoordPair are created by class method withX:y:, then 
initialized by instance method initializeX:andY:. In the class method, 
the self in (self new) refers to the class object, not to any instance. The 
class, like all classes, inherits the new method from class Class; the new 
method creates and answers a new, uninitialized object that is an instance 
of class CoordPair. After sending new, class method withX:y: finishes 
by sending the message initializeX:andY: to the new object. Method 
initializeX:andY: initializes instance variables x and y, then answers 
self—when message withX:y: is sent to the CoordPair class object, the fi- 
nal answer is the newly allocated, correctly initialized instance. This idiom is 
common: a Smalltalk object is created by sending some message to its class, 
and because the corresponding class method has no access to the instance 
variables of the new object, it initializes the object using an instance method. 
(The class object has no access to the instance variables of any other object, 
not even one of its own instances.) 


Method initializeX:andY: is commented as private, which means that it is 
intended to be used only by other methods of the class, or of its subclasses. 
Private methods are an essential part of object-oriented programming, and 
in different object-oriented languages “private” is interpreted in slightly dif- 
ferent ways. In Smalltalk, private methods are purely a programming con- 
vention, which is not enforced by the language. Methods that initialize in- 
stance variables are often private. 


An instance of class CoordPair is printed by the print method, in the 
form “(x,y).’ The method's body is a sequence of message sends. The print 
message may be sent to any object; it is part of the protocol for all ob- 
jects (Section 10.4.1, page 636). Names x and y refer to instance variables; 
left-round and right-round refer to predefined objects stored in global 
variables, and ', is a literal symbol. 


Every instance of class CoordPair provides two methods, x and y, which an- 
swer the values of the corresponding instance variables x and y. 


Instances of class CoordPair are operated on as vectors by methods *, +, 
and -. The * method takes a scalar argument k and multiplies the receiver 
by k. Because the CoordPair abstraction is immutable, the method does 
not mutate any instance variables; instead, it multiplies each instance vari- 
able by k, then uses the resulting products to create a new object of class 
CoordPair. 


The + and - methods implement vector sum and difference. To compute 
the sum of the receiver vector self and the argument vector coordPair, 
the methods need access not only to the instance variables x and y of the 
receiver, but also to the x and y coordinates of the argument coordPair. 
They get that access by sending messages x and y to coordPair. 


The definition of class CoordPair illustrates basic Smalltalk. For more advanced 
techniques, we examine the definitions of classes Picture and TikzCanvas, which 
illustrate looping over lists, then the shape classes, which illustrate inheritance. 


10.1.3 Pictures: Programming with lists and blocks 


Class Picture provides an abstraction of a list of shapes. Shapes can be added to 
the picture, and the shapes can be drawn on a canvas. 


empty The class answers a new instance of itself, which contains no shapes. 


(a) Class protocol for pictures 


add: aShape The shape is added to those remembered by the 
receiver. 


renderUsing: aCanvas The receiver sends messages to aCanvas, drawing 
all of its remembered shapes, then answers itself. 


(b) Instance protocol for pictures 


Figure 10.3: Protocols for pictures 


617. (shape classes 615) += 1615 619> 


(class Picture 
[subclass-of Object] 
[ivars shapes] ; the representation: a list of shapes 


(class-method empty () Tittrrreeeey Lnitialization 
((self new) init)) 

(method init () ; private 
(set shapes (List new)) 


self) 

(method add: (aShape) trttrr47¢¢77 Add a shape, 
(shapes add: aShape) Sieh? Peply with the picture 
self) 


(method renderUsing: (aCanvas) 
(aCanvas startDrawing) 
(shapes do: 7; draw each shape 
[block (shape) (shape drawOn: aCanvas)]) 
(aCanvas stopDrawing) 
self) 


Figure 10.4: Definition of class Picture 


The protocols for pictures are shown in Figure 10.3. The class protocol in- 
cludes just one message: sending empty to the class creates an empty picture. 
The instance protocol includes messages add:, which adds a shape to a picture, 
and renderUsing:, which asks a picture to draw itself on a canvas. The protocols 
are implemented by the class definition in Figure 10.4. A picture is represented by 
the single instance variable shapes, which is a list of shapes. An empty picture is 
initialized using the same idiom asinclass CoordPair: class method empty calls pri- 
vate initialization method init, which initializes shapes with an empty list. (Class 
List is predefined.) 

To add a shape to a picture, method add: adds the shape to the shapes list. 
To render a picture on a canvas, method renderUsing: prepares the canvas, draws 
each shape, then notifies the canvas that drawing is complete. 

Shapes are drawn by a loop, which is implemented using only message passing; 
unlike Impcore or Scheme, Smalltalk does not have looping syntax. The loop is 
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new Answer a new instance of itself, which is not yet prepared for drawing. 


(a) Class protocol for canvases 


startDrawing Prepare the receiver for drawing. 


stopDrawing Tell the receiver that drawing is complete. 


drawEllipseAt:width:height: aCoordPair aNumber aNumber 
The receiver issues drawing commands for an ellipse 
centered at the point with the given coordinates and 
with the given width and height. 

drawPolygon: aList The receiver issues drawing commands for a polygon 
whose vertices are specified by the given list, which is 
a list of CoordPairs. 


(b) Instance protocol for canvases 


Figure 10.5: Protocols for canvases, including TikzCanvas 


implemented by sending the do: message to the list of shapes. The argument to the 
do: message is a block, which is created by evaluating the special syntactic form 


exp ::= [block ({ argument-name}) {exp}] 


Just like a lambda expression in Scheme, a block expression evaluates to a closure. 
But a block is not a function; it is an object, and it is activated when it receives the 
right sort of message. 

In the renderUsing: method of class Picture, the block is activated once for 
each shape in the list shapes. That’s accomplished by sending the do: message to 
the list, with the block as an argument. Sending do: isa lot like applying wScheme’s 
app function; when passed the block shown in the figure, the do: method ends 
up sending the drawOn: message to each shape in shapes, with the canvas as the 
argument. This is higher-order imperative programming at its finest: without any 
special-purpose syntax, we achieve the effect of a for loop.® 


10.1.4 Acanvas, on which pictures can be drawn 


A canvas object hides a secret: how to draw ellipses and polygons, and how to sur- 
round them with the bureaucracy that the rendering engine requires. A simple can- 
vas protocol is shown in Figure 10.5, and class TikzCanvas, shown in Figure 10.6 
on the facing page, encapsulates what I know about drawing simple pictures with 
IsTpxX’s TikZ package. Like all good encapsulation, the design makes the code easy 
to change: to switch to a different drawing language, like PostScript, I could simply 
define a new class using the same protocol (Exercise 5). 

The methods of class TikzCanvas are ugly—because puSmalltalk does not have 
strings, the TikZ syntax can be emitted only by a sequence of print messages, 
which are sent both to literal symbols and to predefined Unicode characters like 
left-curly. 

Like the renderUsing: method of class Picture, the drawPolygon: method it- 
erates over a list, but here it is a list containing the vertices of the polygon. The 
block—which is effectively the body of the loop—prints the coordinates of a vertex, 
followed by the -- symbol. 


5The drawOn: message is part of the protocol for shapes; it is defined below. 


619. (shape classes 615) += 
(class TikzCanvas 


<1617 620> 


[subclass-of Object] 

(method startDrawing () 
('\begin print) 
(left-curly print) ('tikzpicture print) (right-curly print) 
(left-square print) ('x=4pt,y=4pt print) (right-square println)) 


(method stopDrawing () 
C'\end print) 
(left-curly print) ('tikzpicture print) (right-curly println)) 


(method drawPolygon: (coord-list) 
('\draw print) (space print) 
(coord-list do: [block (pt) (pt print) ('-- print)]) 
C'cycle print) 
(semicolon println)) 


(method drawEllipseAt:width:height: (center w h) 
('\draw print) (space print) (center print) ('ellipse print) 
(left-round print) 
((w div: 2) print) (space print) ('and print) (space print) 
(Ch div: 2) print) 
(right-round print) 
(semicolon println)) 


Figure 10.6: Definition of class TikzCanvas 


The drawEllipseAt:width:height: method requires no iteration. It converts 
width and height to radii, which are what TikZ wants, and then it prints. 


10.1.5 Shapes: Taking inheritance seriously 


The CoordPair class illustrates arithmetic and printing, which are found in all lan- 
guages. The Picture and TikzCanvas classes illustrate two of Smalltalk’s built-in 
abstractions: lists and blocks, which are similar to abstractions found in wScheme 
(lists and closures). Our final example—shapes—illustrates inheritance, which is 
found only in object-oriented languages. Inheritance is used to create related ab- 
stractions that share functionality. 

Notionally, every shape is inscribed in a square. The square is specified by its 
location and its radius, which is halfits side. A square also has nine “control points,” 
each of which is named with a symbol: 


"Northwest "North "Northeast 
"West "East 
"Southwest "South "Southeast 


Our example picture includes three different shapes. And although each shape 
draws itself differently, each shape handles the circumscribing square and its con- 
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new The class answers a new instance of itself, whose radius is 1 and whose 
center control point is at the coordinate origin. 


(a) Class protocol for shapes 


location: aSymbol Answers the location of the receiver’s control point 
that is named by the given symbol ('North, 
'South, ...). If the given symbol does not name a 
control point, the result is a checked run-time error. 


locations: symbols Given a list or array symbols, each of which names a 
control point, return the list of the corresponding 
locations. If any symbol in symbols does not name a 
control point, the result is a checked run-time error. 


adjustPoint:to: aSymbol aCoordPair 
Changes the location of the receiver so that the control 
point named by the given symbol is located at the 
given coordinate pair. Answers the receiver. If the 
given symbol does not name a control point, the result 
is a checked run-time error. 


scale: aNumber Multiply the size (radius) of the receiver by the given 
number. 
drawOn: aCanvas The receiver draws itself on the given canvas. 


(b) Instance protocol for shapes 


Figure 10.7: Protocols for shapes 


trol points in the same way. For that reason, all shapes can share an implemen- 
tation of the first part of the shape protocol: messages location:, locations:, 
adjustPoint:to:, and scale: (Figure 10.7). Each shape needs its own implemen- 
tation of only one method: drawOn:. This kind of “sharing with a difference” is 
exactly what inheritance is designed to provide. 


* Shared methods location:, locations:, adjustPoint:to:, and scale: are 
defined in a common superclass, which I call Shape. Class Shape (Figure 10.8, 
on the next page) also defines instance variables center and radius, which 
specify the square in which the shape is inscribed. 


* Each drawOn: method is defined in a unique subclass, which inherits the rep- 
resentation and the other methods of class Shape. 


My design separates concerns: the superclass knows only how to use control points 
to move and resize shapes, and a subclass knows only how to draw a shape. 
Because each subclass defines only the drawOn: method, the subclass defini- 
tions are tiny, requiring little programming effort. For example, a circle is drawn 
by drawing an ellipse whose width and height are both twice the radius of the cir- 
cumscribing square: 
620. (shape classes 615) += 1619 621b> 
(class Circle 

[subclass-of Shape] 

7; no additional representation 

(method drawOn: (canvas) 

(canvas drawEllipseAt:width:height: center (2 * radius) (2 * radius))) 


621a. (definition of class Shape 621a)= 
(class Shape 
[subclass-of Object] 
[ivars center radius] ;; CoordPair and number 


(class-method new () 

((super new) center:radius: (CoordPair withX:y: 0 0) 1)) 
(method center:radius: (c r) ;; private 

(set center c) 

(set radius r) 

self) 


(method location: (point-name) 
(center + ((point-vectors at: point-name) * radius))) 


(method locations: (point-names) [locals locs] 
(set locs (List new)) 
(point-names do: [block (pname) (locs add: (self location: pname))]) 
locs) 


(method adjustPoint:to: (point-name location) 
(set center (center + (location - (self location: point-name)))) 
self) 


(method scale: (k) 
(set radius (radius * k)) 
self) 


(method drawOn: (canvas) 
(self subclassResponsibility)) 


Figure 10.8: Definition of class Shape 


What’s new here is in the subclass-of form: class Circle inherits from Shape, not 
from Object. So it gets the representation and methods of Shape. 

As another example, class Square also inherits from Shape. Its drawOn: method 
draws the polygon whose vertices are the four corners of the square: 


621b. (shape classes 615) += 1620 622a> 
(class Square 
[subclass-of Shape] 
77 no additional representation 
(method drawOn: (canvas) 
(canvas drawPolygon: 


(self locations: '(Northeast Northwest Southwest Southeast) ))) 
) 
The locations: method converts the list of control-point names into a list of co- 
ordinate pairs, which is then sent with drawPolygon:. Other shapes, including 
Triangle, can be defined in the Exercises. 
Both Circle and Square inherit from the superclass, Shape (Figure 10.8). 


+ A shape is created by sending message new to its class. Class method new 
uses the now-familiar pattern of creating a new object, then using a private 
method to initialize it. But there is something different here: to allocate the 
new object, the class method sends the new message to super, not to self. 
Sending a message to super is a language feature that is described in detail in 
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Section 10.3.4 (page 632); for now, accept that sending new to super sends the 
new message to class Shape, but in a way that dispatches to the new method 
inherited from class Class. Sending new to self would dispatch to the rede- 
fined new method, which would cause infinite recursion. 


The location associated with a control point is computed by the location: 
method, which finds a vector associated with the control point, multiplies 
that vector by the radius, and adds the resulting vector to the center. 
To associate a vector with each control point, I define a global variable 
point-vectors of class Dictionary (page 646). 
622a. (shape classes 615) += <1621b 
(val point-vectors (Dictionary new)) 
(point-vectors at:put: 'Center (CoordPair withX:y: 0 0)) 


(point-vectors at:put: 'East (CoordPair withX:y: 1 0)) 
(point-vectors at:put: 'Northeast (CoordPair withX:y: 1 1)) 
j «+. Six more definitions follow ... 


Sending at:put: to a dictionary stores a key-value pair. Sending at: to the 
dictionary, as in method location: of class Shape, answers the value stored 
with the given key. 


A list of locations is computed by the locations: method, which uses the 
same do: as the renderUsing: method of the Picture class. In locations:, 
the do: loop adds each location to a list locs, which is stored in a local vari- 
able of the method. 


A shape is moved by adjusting a given control point to a given location. The 
adjustPoint:to: method updates the center of the shape, computing a new 
center by sending + and - messages to objects of class CoordPair. This arith- 
metic is hidden from clients that send messages to shapes; such clients know 
only about the names of control points, not about vector arithmetic. 


A shape is changed in size by changing its instance variable radius, which is 
done in the scale: method. 


A shape is drawn by sending it the draw0n: message, but if drawOn: is sent 
to an instance of class Shape, the message send fails with a special run-time 
error: 
622b. (transcript 611a) += <1612c 632a> 
-> ((Shape new) drawOn: canvas) 
Run-time error: subclass failed to implement a method it was responsible for 
Method-stack traceback: 
In shapes.smt, line 105, sent ‘subclassResponsibility‘ to an object of class Shape 
In standard input, line 45, sent ‘draw0n:*‘ to an object of class Shape 


Sending draw0n: to an instance of class Shape causes an error because class 
Shape is not meant to be instantiated—only subclasses like Circle, Square, 
and Triangle are meant to be instantiated. A class like Shape, which is meant 
to collect reusable methods but not to be instantiated, is called an abstract 
class. Subclasses then inherit from the abstract class. A subclass that is meant 
to be instantiated may inherit as many methods as it likes, except those that 
send subclassResponsibility—those methods must be redefined. 


In Smalltalk, the “abstract class,” like the “private method,” is a program- 
ming convention, not a language feature. Client code should never create an 
instance of an abstract class; it should instead create instances of concrete 
subclasses. 


10.1.6 Object-orientation means dynamic dispatch 


The shapes examples uncover some of the essence of Smalltalk. In some ways, 
Smalltalk resembles Impcore: 


* Smalltalk has no static types. 


* Idiomatic code is imperative: it uses set and it evaluates expressions in se- 
quence. 


+ A message send, like an Impcore function call, always uses a name. 


In Impcore, calling a function requires you to name the function, and in Smalltalk, 
sending a message requires you to name the message. But in Impcore, a function 
name always refers to the same function, no matter what arguments are passed; 
the code that is executed is determined by the caller. Whereas in Smalltalk, a mes- 
sage name may be implemented by any number of methods, and the code that 
is executed—the method that a message is dispatched to—is determined by the re- 
ceiver. For example whenever a + or - message is sent to an instance of class 
CoordPair, the message dispatches to the + or - method defined in class CoordPair. 
But in the body of those methods, the + and - messages are sent to instances of nu- 
meric classes, and those messages dispatch to different methods. 

Even a single message send from a single place in the source code can be 
dispatched to different methods on different evaluations. For example, in the 
renderUsing: method of class Picture, the drawOn: message is sent to each of a 
list of shapes. But depending on whether a shape is a Circle, Square, or Triangle, 
that message dispatches to a different method—even though the source code be- 
ing evaluated is the same each time. When a message is sent, it dispatches to a 
method that is selected by an algorithm called dynamic dispatch. Dynamic dispatch 
is the essence of object-oriented programming; Smalltalk’s version is explained in 
Section 10.3.4 (page 631). 


10.1.7 Review and analysis 


The shapes examples illustrate message sends, method dispatch, protocols, repre- 
sentation, object creation, and inheritance. 


+ Acomputation is implemented by a small army of objects that exchange mes- 
sages. Each message is dispatched to a method, which is chosen at run time 
based on the class of the receiver. As often as not, a method is executed for 
its side effects, like updating instance variables, or printing. 


« Amethod may be designated private, which means that its use should be lim- 
ited to certain senders. For example, a message designated as private might 
be sent only by an object to itself, or by a class to its instances. In Smalltalk, 
the designation is purely advisory: it records a programmer’s intent, but it 
is not enforced. In practice, “private” may also designate a message that is 
intended to be sent by instances of a class to other objects that are believed 
to be of the same class. 


* The set of messages an object understands, together with the behavior that 
is expected in response to those message, is the object’s protocol. Because 
Smalltalk does not have a static type system, protocols are specified infor- 
mally. An object’s protocol is determined by the class of which the object 
is an instance. The same protocol can be implemented by many different 
classes, which are often related by inheritance. But they don’t have to be 
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related: an existing protocol can be implemented by an entirely new class 
that does not inherit from any existing implementation, like PSCanvas (Ex- 
ercise 5). 


Although Smalltalk does not have a static type system, it does have a way to 
ensure that a message is accompanied by the correct number of arguments: 
the number of arguments is determined by the name of the message. If the 
name begins with a letter, like drawOn:, the message expects a number of ar- 
guments equal to the number of colons in the name. If the name begins with 
a nonletter, like +, the message expects exactly one argument. Ensuring that 
the number of arguments matches the number expected by the name costs 
almost nothing, but like a type, it serves as documentation that is checked by 
the compiler. And it catches mistakes at compile time. In proper Smalltalk- 
80 syntax, colons break the name into parts, which are interleaved among the 
arguments. This concrete syntax, while unusual, leads to code that I enjoy 
reading (Section 10.12). 


An object is represented by a fixed set of named instance variables. An object's 
instance variables are visible only to the object’s own methods; they are hid- 
den from all other objects, even from other instances of the same class. And 
an object’s instance variables form the product in the sum of products repre- 
sentation mentioned in Chapters 8 and 9, which is so useful for representing 
linked data structures. 


A new object is created by sending a message to its class, often the new mes- 
sage. The message dispatches to a class method, which allocates a new ob- 
ject and may also invoke an instance method to initialize the new object’s 
instance variables. Occasionally a new object is created by evaluating some 
other syntactic form, like a block expression, a literal integer, a literal sym- 
bol, or a class definition. 


Every class definition specifies a superclass, from which the new class inherits 
both methods and instance variables. A class can be defined whose sole pur- 
pose is to be inherited from, like the Shape class. Such a class, which is not 
intended for instantiation, is called an abstract class. A class whose methods 
send the subclassResponsibility message is always abstract. 


Although Smalltalk shares ideas with procedural and functional languages, 
it does many things in its own way. 


«+ A method resembles a function or a procedure, and an object resembles 
a bundle of functions that share mutable state. And since objects them- 
selves are sent with messages and are returned as answers, object-oriented 
programming resembles programming with higher-order functions, only 
more so: any time an object is sent with a message, the message may set off 
a higher-order computation. This is why we study functions before objects. 


* In Impcore, Scheme, and ML, conditional expressions are a normal way 
to make decisions. A conditional expression might ask, “Are you a circle 
or a triangle or a square?” and then draw the shape accordingly. Not in 
Smalltalk! Instead, decisions are made via dynamic dispatch: code just sends 
the drawOn: message, and based on the class of the receiver, method dispatch 
decides how to draw it. 


Multiple classes that all respond to drawOn: form a sum in the sum of prod- 
ucts mentioned above and in Chapters 8 and 9. And because draw0On: is dis- 
patched dynamically, new elements (new shapes) can easily be added to the 


sum without touching any existing code. This open extensibility, which can't 
be replicated using standard algebraic data types, is characteristic of object- 
oriented programming. 


Making decisions via dynamic dispatch influences the structure of programs: 
compared with the number of function definitions and function calls in 
a functional program, a similar object-oriented program likely has more 
method definitions and more message sends. For example, to draw a pic- 
ture, we send messages to shapes, which send messages back to the picture 
object. For a programmer who is used to procedural or functional program- 
ming, distributing a computation over multiple methods defined on multiple 
classes may make it hard to identify the algorithm: the “procedure,” meaning 
the sequence of steps being performed, is not written in one place. 


Moving from procedural programming to object-oriented programming re- 
quires a change in mindset. If you are used to seeing the steps of an algorithm 
laid out in sequence in a single block of code, you are going to be frustrated by 
object-oriented programming: what the procedural programmer thinks of as 
a simple sequence of commands is usually distributed over many methods 
defined on many classes, and it may be hard to identify. The object-oriented 
programmer focuses on the protocols. If the protocols are well designed and 
each object does one job, each individual method becomes much easier to 
understand than a typical procedure full of conditionals and while loops. 
Moreover, although a conceptual procedure may be hard to identify, the in- 
dividual commands become easy to reuse: for example, a class that inher- 
its from Shape reuses everything except the drawOn: method. Learning to 
design with protocols and message passing—though difficult—is the key to 
becoming a productive object-oriented programmer. 


In Smalltalk, the initial basis plays a greater role than in Impcore, Scheme, 
or ML. Even basic control structures and data structures, like conditionals, 
loops, and lists, are coded in the initial basis; they are not part of the lan- 
guage proper. To program effectively in Smalltalk, you must learn about the 
predefined classes, like the lists and dictionaries used in the pictures exam- 
ple. 


10.2 DATA ABSTRACTION ALL OVER AGAIN 


A Smalltalk class defines an abstraction. And as an abstraction, a Smalltalk class is 
subject to the same design criteria that apply to an abstract data type in a Molecule 
module (Section 9.6). In a good design, the abstractions are well thought out and 
are specified using mathematics or metaphor. The operations on the abstraction— 
the methods defined on the class—have costs that are clearly stated. And to be sure 
the code is right, the implementation of the abstraction is accompanied by a rep- 
resentation invariant and an abstraction function. 

Although object fits within the same data-abstraction framework as abstract 
types, objects are not abstract types and Smalltalk is not Molecule; they have dif- 
ferent capabilities, and they are customarily used in different ways. 


« An object-oriented abstraction, like any other abstraction, is either mutable 
or immutable. But the choice is influenced by the surroundings. Smalltalk, 
which is built on set expressions, favors mutable abstractions, while Mol- 
ecule, which is built on case expressions, favors immutable abstractions. 
And in Smalltalk, as in other object-oriented languages, the customary, pre- 
defined abstractions tend to be mutable. 
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Data abstraction for “open” and “closed” systems 


Systems based on abstract data types are “closed,” and can thereby be made re- 
liable. Systems based on objects and protocols are “open,” and can thereby be 
made extensible. 


Using abstract data types, as in Molecule, a representation is hidden in a mod- 
ule, and access is mediated by a module type that exports an abstract type T’. 
The line between “visible” and “hidden” is fixed: 


* Only operations inside the module can see the representation of values of 


type T. 


+ An operation inside the module can see the representation of any value 
of type 7’, no matter where it comes from. 


Once the module is sealed, the representation of T can’t be seen by new mod- 
ules. And new abstractions can’t be made compatible with T’: a new module’s 
abstract types, even if defined identically to 7’, cannot be used in a context that 
expects 7’. New, compatible code can be added only by opening up an existing 
module and editing it; the interface used to seal the module might also need 
editing. Code added outside the module can’t extend its capabilities but also 
can't make it fail. 


Using objects, as in Smalltalk, a representation is hidden inside an object, and 
access is mediated by a protocol. The line between “visible” and “hidden” is 
drawn differently: 


* Only methods defined on an object can see that object’s representation. 


« A method defined on an object can see only that object’s representation, 
not the representation of any other object. This principle, which Cook 
(2009) calls the autognostic principle, is a defining characteristic of object- 
oriented programming. 


The representation of an object can be seen by new code, provided that code 
appears in methods that are defined in a new subclass. And new abstractions 
can be made compatible with old ones: if a new object implements an old pro- 
tocol, then it can be used in any context that expects the old protocol. An object- 
oriented system can be extended without editing existing code. 


* Like Molecule functions, Smalltalk methods can be classified as creators, 
producers, observers, or mutators. But in Molecule, all the functions are 
specified in a single module type. In Smalltalk, the methods are part of two 
protocols. The instance protocol specifies only mutators, producers, and ob- 
servers, but not creators. By definition, a creation message is sent in order 
to create an instance where none yet exists, so it can’t be sent to an instance. 
A creation message is sent to an object’s class, and an object’s creators are 
therefore part of a class protocol. 


Objects and abstract data types support data abstraction in different ways, and 


these differences lead to differences in client code. 


* In Molecule, an abstraction is specified by a named abstract data type, and 
operations of the abstraction work only with values of that type. In Smalltalk, 
an abstraction is specified by a protocol, and operations of the abstraction 
work with objects of any class that implements the protocol. If an object 
implements the fraction protocol, then it walks like a fraction, talks like a 
fraction, and exchanges messages in the protocol for fractions—so even if its 
definition doesn’t inherit from class Fraction, for programming purposes 
it’s a fraction. Because an object’s behavior is what matters, this property is 
called behavioral subtyping, or by Ruby programmers, “duck typing.” 


In a Smalltalk method, se1f is the only object whose representation is acces- 
sible. Objects sent as arguments must implement the expected protocols, but 
a method defined on the receiver cannot see their representations. Methods 
that wish they could see arguments’ representations, like + and - on class 
CoordPair, have to send messages to those arguments instead—usually mes- 
sages like x and y. In Molecule, the analogous operations get to see all rele- 
vant representations directly. 


A Smalltalk class can specify not a single abstraction, but a family of related 
abstractions. Members of the family are implemented by subclasses. Ex- 
amples shown in this chapter include shapes, numbers, and “collections.” 
Additional examples found only in full Smalltalk include input streams and 
user-interface widgets. 


Compared with Molecule modules, Smalltalk classes are more flexible and easier 
to reuse, but operations that wish to see multiple representations are harder to im- 
plement. And unlike Molecule, Smalltalk does not have a type checker, so it cannot 
guarantee that every operation is given abstractions that it knows how to work with. 
To understand how these trade-offs work, study the design and implementation of 
the Collection hierarchy, shown in Sections 10.4.5, 10.7.1, 10.7.2, and 10.9. 


10.3 THE {ASMALLTALK LANGUAGE 


10.3.1 Concrete syntax and its evaluation 


The concrete syntax of jiSmalltalk is shown in Figure 10.9 on the next page. Three 
of the first four expression forms are shared with Impcore and Scheme: variables, 
set, and begin. All three languages also have literal expressions, but each one hasa 
different set— Smalltalk has integer literals and symbol literals as in uScheme, but 
in place of list literals, «Smalltalk has array literals, and it has no Boolean literals. 

pSmalltalk’s remaining expression forms are found neither in Impcore nor in 
pScheme. Most important, instead of function application wSmalltalk has message 
send. Ina send, the message, like an Impcore function, is identified by name.° Ev- 
ery message name has an arity, which is the number of arguments that the message 
expects. If the message-name begins with a nonletter, its arity is 1. If the message- 
name begins with a letter, its arity is the number of colons in the name. 

In addition to message send and to the shared forms, a Smalltalk expression 
can be a block, which is like a lambda abstraction in Scheme. A block specifies 


®Impcore’s functions are not values, but jzScheme’s functions are values. Are sSmalltalk’s functions 
values? It depends what you mean by “function.” If you mean “block,” then yes, blocks are values. If you 
mean “message name,” then no, message names are not values. (In Smalltalk-80, the message name is 
called a message selector, and it can be given as a value with the perform: message.) 
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exp = literal 

variable-name 

(set variable-name exp) 

(begin { exp} ) 

(exp message-name { exp} ) 

[block (¢ { argument-name} ) { exp} ] 
FY { exp} 3 

(return exp) 

(primitive primitive-name { exp} ) 
(compiled-method (formals) [[locals locals] | { exp} ) 
literal ::= integer-literal 

' symbol-name 

n¢ { array-element } ) 


array-element 
= Integer-literal 
| symbol-name 
| ({array-element} ) 


formals ::= { formal-parameter-name} 

locals := { local-variable-name} 

def = (val variable-name exp) 
| exp 


| (define block-name (formals) exp) 

| (class subclass-name 
[subclass-ofsuperclass-name] 
[ [ivars { instance-variable-name} 1] 
{ method-definition } ) 

(use file-name) 

unit-test 


unit-test ::= (check-expect exp exp) 
(check-assert exp) 
(check-error exp) 
(check-print exp name) 


method-definition 
i= (method method-name (formals) [[locals locals] | {exp}) 
| (class-method method-name (formals) [[locals locals] | {exp}) 


numeral ::= token composed only of digits, possibly prefixed with a plus 
or minus sign 


any *-name 
::= token that is not a bracket, a numeral, or one of the “re- 
served” words shown in typewriter font 


Figure 10.9: Concrete syntax of Smalltalk 


zero or more formal parameters and a body. The body contains a sequence of ex- 
pressions, which are executed in, well, sequence. Because parameterless blocks 
are used often to implement control flow, they are supported with some syntactic 
sugar: the wSmalltalk expression {e, --- e,% stands for [block () €1 --- en]. 
This syntax is borrowed from Ruby, a descendant of Smalltalk-80.’ 

Expression forms for literals, variables, set, and begin are evaluated as in Imp- 
core or 4Scheme—though it may be worth noting that the evaluation of a literal 
expression allocates a new object. But message send, although it may look like 
a function call, is its own beast; it is discussed in Section 10.3.4 (page 631). And 
a block, whether it is written using the block keyword or the curly braces, is eval- 
uated very much like jsScheme’s lambda: it captures an environment and forms a 
closure. 

The last three expression forms in Figure 10.9 are not related to anything in 
Impcore or jsScheme. The return form is a control operator that is subtly different 
from the control operators in Chapter 3: a return is evaluated by terminating the 
method in which it appears. A primitive expression is evaluated almost like a call 
to a primitive function in Impcore: the primitive is named, it takes arguments, and 
it returns one object as a result. And a compiled-method expression is evaluated a 
little bit like a block, except it does not capture an environment; a compiled-method 
evaluates to an object that contains only code, which can be added to an existing 
class as a new method. 

The definition forms of jsSmalltalk include the usual val, exp, define, use 
forms found in Impcore and ~Scheme, as well as a class definition. The famil- 
iar forms are evaluated as expected, except that in Smalltalk, define defines a 
block, not a function. Class definitions are unique to Smalltalk; evaluating a class 
definition adds a new class object to the global environment. Class objects and their 
creation are discussed in detail in Section 10.11.4 (page 694). 

Smalltalk also has the same unit-test forms as Impcore and ppScheme, plus 
an additional check-print form: provided an object prints as a single token, the 
check-print form can be used to test its print method. 

To understand how message sends and class objects work, we should first study 
pSmalltalk’s values. 


10.3.2 Values 


In Smalltalk, every value is an object. An object’s properties are determined by 
its class, so working with objects requires knowledge of the predefined classes and 
their protocols. The protocols are described in detail below (Section 10.4), but there 
are a lot of them, and a preview will help. 


Properties shared by all objects 


Every object is an instance of some class, which eventually inherits from class 
Object. Therefore every object responds to the messages in Object’s protocol. 
These messages include =, ==, println, class, and many others. They are a bit 
like predefined functions in other languages, with an important difference: they 
can be redefined. 


7Smalltalk-80 writes blocks in square brackets, but in this book, square brackets work just like round 
brackets—you mix square and round brackets in whatever way you find easiest to read. 
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The undefined object, nil 


The object nil is the sole instance of class UndefinedObject. It conventionally rep- 
resents a bad, missing, undefined, or uninitialized value. Smalltalk’s nil is quite 
different from the nil used in some dialects of Lisp, Scheme, Prolog, and ML, 
which represents the empty list. 


Other predefined objects 


A literal symbol, written 'name, is an object of class Symbol. Like all objects, sym- 
bols can usefully be printed and compared for equality. A symbol also understands 
a hash message, to which it responds with an integer. 

The Boolean objects true and false are predefined. A Boolean object re- 
sponds to the message ifTrue:ifFfalse:, whose arguments are two blocks. De- 
pending on the value of the receiver, ifTrue:ifFalse: evaluates one block or the 
other. Boolean objects also respond to many other messages, including and:, or:, 
and not. 

A block is an object that understands messages value, value:, value: value:, 
and so on. A block behaves just like a lambda abstraction, except that it is activated 
by sending it one of these messages, not by applying it—Smalltalk does not have 
function application. A block also responds to the message whileTrue:, whose ar- 
gument isa block; the method keeps sending value to self, andas long the receiver 
answers true, the argument block is executed. 


Class objects 


Every class definition creates a class object, which itself has a class that inherits 
(through intermediaries) from class Class. The class object can respond to new 
and possibly to other class-dependent initialization messages. And the class object 
is an instance of another class: The object representing class C is an instance of C’s 
metaclass. (It is the only instance of C’s metaclass.) The metaclass holds C’s class 
methods. In more detail, if an object c is an instance of class C, the messages that 
c can respond to are those defined on C’s class object. Similarly, the messages that 
class C can respond to are those defined on C’s metaclass. Because every metaclass 
inherits from class Class, which defines new, every class object can respond to a 
new message. 

In addition to new, class Class defines other methods that enable client code 
to interrogate or alter a class. For example, printProtocol prints all the messages 
that a class and its instances know how to respond to; superclass answers the class 
object of the receiver’s superclass, if any; compiledMethodAt: answers a method; 
and addSelector:withMethod: can add a new method or change an existing one. 
Such reflective facilities, which enable the language to manipulate itself, are even 
more numerous in full Smalltalk-80, in which you can learn the names of meth- 
ods and instance variables, execute methods by name, create new subclasses, and 
much more, all by sending messages. The reflection methods are so powerful that 
Smalltalk-80’s class browsers and debuggers are implemented in Smalltalk itself. 


10.3.3 Names 


Just as Impcore has distinct name spaces for functions and values, jsSmalltalk has 
distinct name spaces for message names and variables. The name of a message 
is resolved dynamically: until a message is sent, we can’t tell what method will be 
executed to respond to it. The name of a variable is resolved statically; that is, we 
can tell by looking at a class definition what each variable name in each method 


must stand for. In particular, the name of a variable stands for one of the following 
possibilities: 

A formal parameter of a block 

A local variable of a method 

A formal parameter of a method 


An instance variable of an object 


A global variable 


A name stands for the first possibility that is consistent with the source code where 
the name appears. For example, ifa name appears ina block, is nota formal param- 
eter of that block, but is a local variable of the method in which the block appears, 
then it’s a local variable (possibility 2). In the implementation, each possibility is 
represented by an environment, and the environments are combined into a single 
environment using the <+> function (chunks 690a and 691c). Not all possibilities 
apply in all contexts; for example, a name in a top-level expression doesn’t appear 
inside a method or a class definition, so it must stand either for a parameter of a 
block or for a global variable. 

In possibility 4, a name x appearing in a method of class C' can stand for an 
instance variable if x is declared as an instance variable in class C' or in any of C’s 
ancestors. (To avoid confusion, if x is declared as an instance variable of an ancestor, 
it may not also be declared as an instance variable of class C’.) 

The environment in which a name is looked up enforces a form of encapsu- 
lation: the instance variables of an object are visible only to a method executed on that 
object. This encapsulation of the instance variables hides them from all other ob- 
jects, even other objects of the same class. This encapsulation mechanism differs 
from Molecule’s mechanism: in Molecule, if an operation is located inside a mod- 
ule that defines an abstract type, it automatically has access to the representation 
of any value of that type. A Smalltalk method, by contrast, has access only to the 
representation of its receiver. To an object, all other objects are abstract. 

The names self and super are not, properly speaking, variables; for one thing, 
self and super cannot be mutated with set. Within a method, self stands for the 
object that received the message which caused the method to be executed. The 
name super stands for the same object, but with different rules for method dis- 
patch, which are described in the next section. 

Unlike the name of a variable, the name of a message—called a message selector 
—does not by itself determine what method will be executed when the message is 
sent. Instead, the method is determined at run time by a process called dynamic 
dispatch. Dynamic dispatch determines a method based on the combination of the 
message selector and the class of the object to which the message is sent. This ob- 
ject, the receiver, may be different on different executions, even on different iter- 
ations of the same loop—and so may be the method. 


10.3.4 Message sends, inheritance, and dynamic dispatch 


Except when a message is sent to super, an object of class C' responds to any mes- 
sage for which a method is defined in C—or in any of C’s ancestors. When an object 
of class C receives a message with selector m, it looks in C’s definition for a method 
named m. If that fails, it looks in the definition of C’s superclass, and so on. When 
it finds a definition of a method for m, it executes that method. If it reaches the 
top of the hierarchy without finding a definition of m, an error has occurred: the 
message is not understood. 
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For example, when location: is sent to an object of class Circle, class Circle 
does not define a location: method, but Circle’s superclass, class Shape, does de- 
fine a location: method, so the message is dispatched to the location: method 
defined on class Shape. On the other hand, if drawOn: is sent to an object of 
class Circle, it is immediately dispatched to the drawOn: method defined on class 
Circle—class Shape is not consulted. 

Unlike an ancestor’s instance variable, an ancestor’s method can be redefined. 
When a method is defined in C and also in an ancestor, and the relevant message 
is sent to an object of class C, it is C’s definition of the method that is executed. 
This method-dispatch rule produces outcomes that might surprise you, so let’s look 
at a contrived example. 

Suppose classes B (the superclass or ancestor) and C (the subclass) are defined 
as follows: 
632a. (transcript 611a) += <1622b 632b> 

-> (class B [subclass-of Object] 
(method m1 () (self m2)) 
(method m2 () 'B)) 

-> (class C [subclass-of B] 
(method m2 () 'C)) 


Method m2, which is defined in superclass B, is also defined in subclass C. Method m2 
is said to be overridden by class C. 

When message m1 or m2 is sent to an instance of class B or C, what happens? 
When m1 or m2 is sent to an instance of class B, the instance answers the symbol B. 
And when m2 is sent to an instance of class C, method dispatch finds the definition 
of m2 within C, and the instance answers the symbol C. But when m1 is sent to an 
instance of class C, the instance’s answer might surprise you: 
632b. (transcript 611a) += <1632a 635b> 

-> (val x (C new)) 
-> (x m1) 
Cc 


The answer C is delivered by the following computation: 


1. When m1 is sent to x, x is an instance of class C, and class C does not define 
method m1. But C’s superclass, class B, does define m1. So the message is dis- 
patched to B’s m1 method, which executes. 


2. B’sm1 method sends message m2 to self—which is to say, to x. The search for 
method m2 begins in x’s class, namely C. 


3. Class C defines m2, so the message send dispatches to that definition. And 
class C’s m2 method answers the symbol C. 


This example illustrates a crucial fact about Smalltalk: the search for a method begins 
in the class of the receiver. Many more examples of method dispatch appear through- 
out the chapter. 

Does method dispatch always begin in the class of the receiver? Almost always. 
A message sent to super is dispatched in a special way. The message is sent to 
self, but the method search begins in the superclass of the class in which the message 
to super appears. That is, unlike the starting place for a normal message send, the 
starting place for a message to super is statically determined, independent of the 
class of the receiver self. This behavior guarantees that a particular method from 
the superclass will be executed. 

We typically send to super when we wish to add to the behavior of an inherited 
method, not simply replace it. The most common examples are class methods that 


initialize objects, like method new in class Shape. A new method is defined on every 
class, and a properly designed new method not only allocates a new object but also 
establishes the private invariants of its class. Simply sending new to self executes 
only the new method defined on the class of the object being created. Butif there are 
invariants associated with the superclass, those invariants need to be established 
too. All the invariants can be established by the following idiom: each subclass 
sends new to super, establishing the superclass invariants, then executes whatever 
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Below, Section 10.4 dives into Smalltalk’s initial basis, starting with the messages 
that every object understands. But some of those messages implement equality 
tests, which deserve a section of their own. 

The issue of when two objects should be considered equal is one we have 
danced around since Chapter 2. Equality is so central, and yet so seldom addressed 
well, that when you encounter a new programming language, it is one of the first 
things you should look at. This section will tell you what to look for. 

Almost all languages support constant-time equality tests on simple, scalar val- 
ues like integers and Booleans. But equality tests on more structured data, like 
records, sums, and arrays, can be done in more than one way—and there is no 
single right way (Noble et al. 2016). Moreover, when a language supports data ab- 
straction, it is all too easy to test equality in the wrong way, by violating abstraction. 
To expose some of the issues, let’s review some designs you've already seen. 


* Chas only one form of equality, and it applies only to scalar data (integers, 
Booleans, floating-point numbers, and similar) and to pointers. Two point- 
ers are equal if and only if they point to the same memory; viewed at a higher 
level of abstraction, C’s == operator tests for object identity. (A well-known be- 
ginner’s mistake is to use == to compare strings for equality; that comparison 
demands strcmp.) Structured data like structs and unions cannot be com- 
pared for equality, and C famously does not have arrays—only pointers and 
memory.® 


LScheme has two forms of equality, written = and equal?. The = operator 
works only on scalar data; given two pairs, it always returns #f—according 
to wScheme’s =, a cons cell is not even equal to itself. The equal? predicate, 
on the other hand, provides structural similarity; it returns #t whenever two 
values have the same structure, even if the structure is arbitrarily large. 


Full Scheme, in which cons cells are mutable, has a more principled design. 
Function equal? acts as in “Scheme, providing structural similarity. Func- 
tion eqv? provides object identity, and it compares not only scalar data but 
also cons cells, vectors, and procedures. And function eq? provides object 
identity on structured data, but on numeric data and character data it is more 
efficient if less predictable than eqv?. 


Object B 637 


Standard ML has “polymorphic equality” comparison on integers, Booleans, 
strings, and mutable reference cells, but not on functions or floating-point 
numbers. Polymorphic equality can compare values of any type that “admits 
equality”; such types include the ones listed above, plus any constructed data 


8“Does not have arrays” stretches the truth. In initialized data, array notation and pointer notation 
mean different things (Van der Linden 1994, chapter 4). 
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(tuple type, record type, or algebraic data type) whose components all admit 
equality. There are even special type variables that admit equality and that 
instantiated only with types that admit equality. Polymorphic equality hacks 
together object identity (for arrays and references) with structural similarity 
(for constructed data) in a hybrid that gets common cases right. 


OCaml, like Scheme, has two forms of equality; the = sign means structural 
similarity, and the == sign means object identity (and is fully defined for mu- 
table types only). 


All these designs get abstract data wrong. For evidence, review the association 
lists in Section 2.9 (page 132). Two association lists should be considered equal if 
and only if each contains all the key-value pairs found in the other. This equiva- 
lence relation, which is the correct one, is coarser than equivalence of represen- 
tation. If two association lists have the same representation, they definitely rep- 
resent the same associations, and therefore if two association lists represent dif- 
ferent associations, they definitely have different representations. But two associ- 
ation lists may have different representations and yet represent the same associa- 
tions. Given such lists, Scheme’s equal? and ML’s polymorphic equality produce 
wrong answers. Smalltalk’s built-in = and == messages, which correspond roughly 
to uScheme’s equal? and =, pose the same risk. To produce right answers, the built- 
in = method may have to be overridden. And overriding it correctly requires deep 
understanding of what it could mean to consider two objects equivalent. 


Notions of equivalence 


To get equality right, Smalltalk uses the same methodology as Molecule. The meth- 
odology is based on a central idea of programming-language theory, called observa- 
tional equivalence. A pointy-headed theorist would say that two things are observa- 
tionally equivalent if there is no computational context that can distinguish them. 
For a programmer who doesn’t normally talk about computational contexts, the 
idea makes more sense as a programming principle: 


Two values should be considered equal if no program can tell them apart. 
The principle has immediate consequences: 


+ A mutable abstraction, like a dictionary, should compare equal only with it- 
self. That’s because two different mutable objects can be told apart by mu- 
tating one and seeing that the other doesn't change. Therefore, on mutable 
data, equality must be implemented as object identity. 


* Structurally similar representations of immutable, non-atomic abstractions, 
like large integers, should be considered equal. 


In Smalltalk, object identity is implemented by the == method, which is defined on 
class Object: 


634. (methods of class Object 634)= 635a> 
(method == (anObject) (primitive sameObject self anObject)) 
(method !== (anObject) ((self == anObject) not)) 


The = method, by contrast, should implement observational equivalence. But 
“any program” shouldn't be allowed to observe a representation; programs are just 
too powerful. Like object identity and ML’s polymorphic equality, an unrestricted 
program can observe differences between objects even when the objects really 


should be considered the same. It’s better to restrict programs by ruling out some 
observations. 


* Abstractions should be considered equivalent when no client code can tell 
them apart. For example, if finite maps are represented as association lists, 
and if no combination of find and bind operations can tell two maps apart, 
then they should be considered equivalent even if they are represented dif- 
ferently (page 132). $10.3 
The pSmalltalk 
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observing differences. For example, perhaps lists ns and ms have the same 
elements right now, so you'd like to consider them equivalent, even if adding 
number 80 to list ns (but not ms) would enable you to tell them apart. 
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* Finally, in a language like Smalltalk, even though reflection can breach the 
abstraction barrier it should not be used to distinguish objects that would 
otherwise be indistinguishable. 


All these restrictions apply to wSmalltalk’s notion of equivalence: 


Two objects are considered equivalent if, without mutating either object or 
using reflection, client code cannot tell them apart. 


In other words, two objects are considered equivalent if at this moment they rep- 
resent the same abstraction. This is the equivalence that is used by wSmalltalk’s 
check-expect and implemented by the = method. 

To implement = correctly on each class requires an understanding of the class’s 
representation invariant and abstraction function (Section 9.6, page 545). But asa 
default, a conservative approximation is defined on all objects: 
635a. (methods of class Object 634) += 1634 655a> 

(method = (anObject) (self == anObject)) 
(method != (anObject) ((self = anObject) not)) 


This default is conservative in the sense that if it says two objects are equivalent, 
they really are. If two objects are equivalent but not identical, however, the default 
= will report, incorrectly, that they are different. 


Identity versus equivalence: An example 


To illustrate the distinction between identity and equivalence, the following exam- 
ple uses lists. The two lists ns and ms are built differently: 


635b. (transcript 611a) += <1632b 636D 
-> (val ns (List new)) 
List( ) addFirst: B 649 
-> (ns addFirst: 3) addLast: B 649 
-> (ns addFirst: 2) List B 649 
-> (ns addFirst: 1) 
-> ns 
List( 123) 
-> (val ms (List new)) 
List( ) 
-> (ms addLast: 1) 
-> (ms addLast: 2) 
-> (ms addLast: 3) 
-> ms 
List( 123) 
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Why no mutation? 


If object-orientation is all about data abstraction, then of course objects should 
be considered different only if client code can tell them apart. But why shouldn't 
the client code be allowed to mutate? In isolation, this restriction makes little 
sense. But in the context of a whole language design, the restriction makes prag- 
matic sense: if you already have object identity, and if you permit client code to 
mutate objects, then client-code observation gives you nothing new. A second 
form of observational equivalence is useful only if it gives different results. 


Lists ns and ms aren't the same object, but because they represent the same se- 
quence of values, they are equivalent: 


636. (transcript 611a) += <1635b 637> 
-> (ns == ms) 
<False> 


-> (ns = ms) 
<True> 


10.4 THE INITIAL BASIS OF tSMALLTALK 


Much of Smalltalk’s power comes from its impressive predefined classes; using 
and inheriting from these classes is an essential part of effective Smalltalk pro- 
gramming. By the standards of Smalltalk-80, ~Smalltalk’s hierarchy of predefined 
classes is small, but by the standards of this book, it is large—sufficient to help 
you learn what Smalltalk programming is like, but too large to digest all at once. 
So you'll start by digesting just the abstractions that the predefined classes repre- 
sent and the protocols they understand (this section, 10.4). That will be enough 
so that you can use the classes. Then to develop good pSmalltalk skills, you can 
go on to study key techniques as illustrated by implementations of some predefined 
classes (Sections 10.6 to 10.9). 


10.4.1 Protocol for all objects 


Every wSmalltalk object responds to the messages in Figure 10.10 (on the next 
page), which are defined on the primitive class Object. Messages = and != test 
for equivalence, while == and !== test for identity. Messages isNil and notNil test 
for “definedness.” 

The print message is used by the Smalltalk interpreter itself to print the val- 
ues of objects; print1n follows with a newline. 

The error: message is used to report errors. The subclassResponsibility 
message, which also reports an error when sent, is used to mark a class as abstract 
(page 622); a method that sends subclassResponsibility is sometimes called a 
“marker method.” Finally, the leftAsExercise message is sent by methods that 
are meant for you to implement, as exercises. 

The three messages class, isKindOf:, and isMemberOf: enable introspection 
into objects. Message class gives the class of a receiver, and messages isKindOf: 
and isMemberOf: test properties of that class. For example, the literal integer 3 is 


== anObject Answer whether the argument is the same object 
as the receiver. 

'== anObject Answer whether the argument is not the same 
object as the receiver. 

= anObject Answer whether the argument should be 
considered equal to the the receiver, even if they 
are not identical. 

'= anObject Answer whether the argument should be 
considered different from the receiver. 

isNil Answer whether the receiver is nil. 

notNil Answer whether the receiver is not nil. 

print Print the receiver on standard output. 

printin Print the receiver, then a newline, on standard 


output. 


error: aSymbol Issue a run-time error message which includes 


aSymbol. 


subclassResponsibility Report to the user that a method specified in the 
superclass of the receiver should have been 
implemented in the receiver’s class. 


leftAsExercise Report to the user that a method should have 
been implemented as an exercise. 
class Answer the class of the receiver. 


Answer whether the receiver's class is the 
argument or a subclass of the argument, aClass. 
Use only at the read-eval-print loop. 


isKindOf: aClass 


isMemberOf: aClass Answer whether the receiver’s class is exactly the 
argument, aClass. Use only at the read-eval-print 


loop. 


Figure 10.10: Protocol for all objects 


an object from some proper subclass of Number, and the literal symbol '3 is not a 
number at all: 


637. (transcript 611a) += 
-> (3 isKindOf: Number) 


<1636 639a> 


<True> 
-> (3 isMemberOf: Number) 
<False> 
-> ('3 isKindOf: Number) 
<False> 


These messages can sometimes distinguish objects that should be considered 
equivalent. They are suitable for building system infrastructure or for exploring 
how Smalltalk works, interactively; except possibly for class, they shouldn't find 
their way into your code. If you’re tempted use isKindOf: or isMemberOf: in defini- 
tions of other methods, don't. Decisions should never be made by using isKindOf: 
or isMemberOf:; they should be made by dispatching to a method that already 
knows what class it’s defined on, as in the definitions of isNil and notNil methods 
on classes Object and UndefinedObject or any method on class True (Section 10.6, 
pages 654 and 655). 
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new The receiver is a class; answer a new instance of 
that class. A class may override new, e.g., if it 
needs arguments to initialize a newly created 


instance. 
name The receiver is a class; answer its name. 
superclass The receiver is a class; answer its superclass, or 


if it has no superclass, answer nil. 


printProtocol The receiver is a class; print the names of all the 
messages it knows how to respond to, plus the 
names of the messages its instances know how 
to respond to. 


printLocalProtocol The receiver is a class; print the names of the 
class and instance methods that are defined by 
this class, not those that are inherited from its 
superclass. 


methodNames The receiver is a class; answer an array 
containing the name of every method defined 
on the class. 


compiledMethodAt: aSymbol 
The receiver is a class; answer the compiled 
method with the given name defined on that 
class. (If no method with that name exists, cause 
a checked run-time error.) 


removeSelector: aSymbol The receiver is a class; if the receiver defines a 
method with the given name, remove it. 


addSelector:withMethod: aSymbol aCompiledMethod 
The receiver is a class; update the receiver's 
internal state to associate the given compiled 
method with the given name. The argument 
method may replace an existing method or may 
be entirely new. The name must be consistent 
with the arity of the method. 


Figure 10.11: Protocol for classes 


10.4.2 Protocol for classes 


Because every class is also an object, a class can answer messages. Every class ob- 
ject inherits from Class, and it responds to the protocol in Figure 10.11 (as well as to 
every message in the Object protocol). Parts of the protocol approximate capabili- 
ties that a full Smalltalk system provides in a graphical user interface: messages 
printProtocol and printLocalProtocol are meant for interactive exploration, 
and message addSelector:withMethod enables you to modify or extend built-in 
classes. 


10.4.3 Blocks and Booleans 


A block is a Smalltalk object that corresponds to a Scheme closure. A block that 
expects no arguments is conventionally written in curly brackets (Smalltalk-80 uses 
square brackets). A bracketed expression of the form {exp}? evaluates to a block 


ifTrue:ifFalse: trueBlock falseBlock 
If the receiver is true, evaluate trueBlock, 
otherwise evaluate falseBlock. 


ifTrue: trueBlock If the receiver is true, evaluate trueBlock, 


otherwise answer nil. 


ifFalse: falseBlock If the receiver is false, evaluate falseBlock, 


otherwise answer nil. 


and: alternativeBlock Ifthe receiver is true, answer the value of the 
argument; otherwise, answer false (short-circuit 
conjunction). 


or: alternativeBlock If the receiver is false, answer the value of the 
argument; otherwise, answer true (short-circuit 
disjunction). 


& aBoolean Answer the conjunction of the receiver and the 


argument. 

| aBoolean Answer the disjunction of the receiver and the 
argument. 

not Answer the complement of the receiver. 


eqv: aBoolean Answer true if the receiver is equivalent to the 


argument. 


Answer true if the receiver is different from the 
argument (exclusive or). 


xor: aBoolean 


Figure 10.12: Protocol for Booleans 


object; the expression inside the brackets is not evaluated until the block is sent 


the value message. 


639a. (transcript 611a) += 1637 639b> 


-> (val index 0) 

-> {(set index (index + 1))? 

<Block> 

-> index 

0 

-> ({(set index (index + 1))? value) 
1 

-> index 

1 


Just like any object, a block can be assigned to a variable and used later. 


639b. (transcript 611a) += 
-> (val incrementBlock ¢(set index (index + 1))3?) 
<Block> 
-> (val sumPlusIndexSquaredBlock ¢(sum + (index * index))?) 
<Block> 
-> (val sum 0) 
0 
-> (set sum (sumPlusIndexSquaredBlock value) ) 
1 
-> (incrementBlock value) 
2 
-> (set sum (sumPlusIndexSquaredBlock value) ) 
5 


<1639a 640aDb 
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Parameterless blocks are used primarily as continuations, to implement loop 
bodies, exception handlers, or conditional expressions, for example. In other lan- 
guages, including Scheme, a conditional expression requires a special syntactic 
form, like (if e; eg €3). This form is evaluated specially by the interpreter, which 
first evaluates e1, then evaluates either e2 or €3, as needed. In Smalltalk, as in full 
Smalltalk-80, if does not have its own syntactic form; it is coded using message 
passing and continuations.’ In ySmalltalk, writing (e; iffrue:ifFalse: e2 e3) 
asks the interpreter to evaluate all three expressions €1, €2, and e3 before dispatch- 
ing to method ifTrue:ifFalse: on the object that e; evaluates to. If e2 and e3 are 
meant to be evaluated conditionally, their evaluation must be delayed by putting 
them in blocks: (e; iffrue:ifFalse: {e293 {¢3%). The effect of the delay is illus- 
trated by this transcript: 


640a. (transcript 61la) += <1639b 640b> 
-> ((sum < 0) ifTrue:ifFalse: {'negative? {'nonnegative?) 
nonnegative 
-> ((sum < 0) ifTrue:ifFalse: 'negative "nonnegative ) 


Run-time error: Symbol does not understand message value 
Method-stack traceback: 
In predefined classes, line 37, sent ‘value‘ to an object of class Symbol 
In standard input, line 154, sent ‘ifTrue:ifFalse:‘ to an object of class False 


On the first line, (sum < 0) produces the Boolean object false. Sending message 
ifTrue:ifFalse: to false causes false to send value to the block £ 'nonnegative?, 
which answers the symbol 'nonnegative, which is the result of the entire expres- 
sion. On the second line, false sends value to the symbol 'nonnegative, which 
results in an error message and a stack trace. 

The ifTrue:ifFalse: message is an example of continuation-passing style (Sec- 
tion 2.10, page 136). Two blocks—the continuations—are passed to a Boolean. The 
true object continues by executing the first block; false continues by executing 
the second. Message ifTrue:ifFalse: and the other continuation-passing mes- 
sages of the Booleans are shown in the top half of Figure 10.12 (on the previous 
page). In addition to classic conditionals, these messages also include short-circuit 
and: and or:. The bottom half of the figure shows messages that implement simple 
Boolean operations. 

Like conditionals, loops are implemented in continuation-passing style. But a 
loop is implemented not by sending a message to a Boolean, but by sending a mes- 
sage to a block, which holds the condition. The condition must be a block because 
it must be re-evaluated on each iteration of the loop. 
640b. (transcript 611a) += <1640a 645a> 

-> ({Csum < 10000)? whileTrue: ¢(set sum (5 * sum)) (Sum println)?) 

25 

125 

625 

3125 

15625 

nil 
When the loop terminates, the whileTrue: method answers nil, which the inter- 
preter prints. 

A parameterless block also understands the messageTrace message, which tells 
the interpreter to show every message send and response during the evaluation of 


°In fact, implementations of Smalltalk-80 have traditionally “open coded” conditionals, preventing 
user-defined classes from usefully defining method ifTrue:ifFalse: (ANSI 1998). The Self language 
manages efficiency without such hacks (Chambers and Ungar 1989; Chambers 1992). 


value Evaluate the receiver and answer its value. 


value: anArgument Allocate a fresh location to hold the 
argument, bind that location to the receiver’s 
formal parameter, evaluate the body of the 
receiver, and answer the result. 


value:value: arg1 arg2 


value:value:value: argl arge arg3 el ; 
The initial basis 
value:value:value:value: arg1 arge arg3 arg4 Smalltalk 
Like value:, but with two, three, or four erusmalita 
arguments. 641 


whileTrue: bodyBlock Send value to the receiver, and if the 
response is true, send value to bodyBlock 
and repeat. When the receiver responds 
false, answer nil. 


whileFalse: bodyBlock Send value to the receiver, and if the 
response is false, send value to bodyBlock 
and repeat. When the receiver responds 
true, answer nil. 


messageTrace Send value to the receiver, and print a trace 
of every message send and reply until the 
receiver answers. 


messageTraceFor: anInteger Send value to the receiver, and print a trace 
of the first anInteger message sends and 
replies. 


Figure 10.13: Protocol for blocks 


the block’s body. The number of sends shown can be capped by instead sending 
messageTraceFor: (Figure 10.13). 

A block may also take parameters. Such a block must be written using the block 
keyword, like this block from the drawPolygon: method of class TikzCanvas: 


(coord-list do: [block (pt) (pt print) ('-- print)]) 


A block that expects one parameter is activated by sending it the value: mes- 
sage with one argument. A block that expects two parameters is activated by 
value: value: with two arguments, and so on up to four parameters. 


10.4.4. Unicode characters 


ifTrue:ifFalse: 


B 639 
Smalltalk doesn’t support strings, but most output can be emitted by printing oe 639b 


symbols. To emit something that can’t be written as a symbol, like a newline or 
a left parenthesis, zSmalltalk code can print a Unicode character, which is typi- 
cally specified by an integer “code point” of 16 or more bits. And because nobody 
wants to read code points, jsSmalltalk defines the following objects of class Char, 
which can be printed by sending them the print message: 


newline semicolon  left-round left-square left-curly 
Space quotemark pright-round right-square  right-curly 


More characters can be created by using new:, as in (Char new: 955). 
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10.4.5 Collections 


All languages need ways of grouping individual data elements into larger collec- 
tions. Some form of collection is usually found in a language’s initial basis; for 
example, Scheme has lists and Molecule has arrays. jsSmalltalk predefines four 
useful collections: sets, lists, arrays, and dictionaries. And defining new collec- 
tions is exceptionally easy, because any new collection can inherit most of its code 
from class Collection or from one of its subclasses. 

Collections are also found in Smalltalk-80, whose collection classes are similar 
to pSmalltalk’s classes but are structured somewhat differently (Section 10.12.3, 
page 705). zSmalltalk’s collection hierarchy is inspired by Budd (1987). 

Acollection is an abstraction, like the abstractions written in Molecule in Chap- 
ter 9. But a collection isn’t a type or a type constructor; Smalltalk provides data 
abstractions using objects, not abstract data types, and object-oriented abstrac- 
tions work differently. In Smalltalk, a collection is an object that responds to the 
collection protocol (Figure 10.15, page 644); whether it has anything to do with the 
Collection class is a matter of convenience. The protocol’s core operations are 
iteration, addition, and removal: 


* Acollection must respond to the do: message by iterating over its contents. 
When a message of the form (collection do: [block (x) body]) is sent, the 
receiver must respond by evaluating body once for each item x that it con- 
tains. A do: method acts like the zScheme app function, but it works on any 
collection, not just on a list. 


Collections are mutable; a typical collection object should respond to mes- 
sage add: by adding the argument to itself, and it should respond to remove: 
by removing the argument from itself. Some collections, like Arrays, have a 
fixed number of elements; when receiving add: or remove: messages, such 
collections report errors. 


The collection protocol is specified and is partially implemented by class 
Collection, which is an abstract class: like class Shape (Section 10.1), it de- 
fines many useful methods but is intended to be inherited from, not instantiated. 
The full implementation is spread out over three abstract classes and four concrete 
classes: 


Collection 


gS 


Set KeyedCollection 


ts Se 


Dictionary SequenceableCollection 


ye OX 


List Array 
Each class has its own role. 


* Class Collection defines an abstraction that contains objects. It is an ab- 
stract class that implements all but four of the methods in the collection pro- 
tocol. The remaining four methods are implemented by subclasses. 


* Class Set implements a set. A set contains objects in no particular order, 
with no duplicates (as decided by =). Class Set implements the four crucial 
methods missing from the Collection class, and it can be used to instantiate 
objects—it is a concrete subclass. 


with: anObject Create and answer a singleton collection holding 
the given object. 


withAll: aCollection Create and answer a collection that holds all the 
elements of the argument. 


Figure 10.14: Class protocol for Collection 


$10.4 
The initial basis 
* Class KeyedCollection refines the Collection abstraction to associate each of Smalltalk 
object with a key—or equivalently, it defines a collection of key-value pairs. 
A keyed collection shares a lot of protocol with an ordinary collection, and 643 


its protocol includes additional messages that can add, retrieve, and mutate 
objects by using a key. KeyedCollection is an abstract class. 


Class Dictionary implements a finite map. Class Dictionary is a concrete 
subclass of KeyedCollection; it is used to instantiate objects. It assumes as 
little as possible about keys: in a dictionary, keys need only to be comparable 
for equality. 


Class SequenceableCollection defines a sequence abstraction, which the 
designers of Smalltalk view as a keyed collection whose keys are consecutive 
integers. Class SequenceableCollection is another abstract class that adds 
yet more protocol to KeyedCollection. 


Class List implements a list, which is a sequence that can grow or shrink. 
Unlike a list in Scheme or ML, a Smalltalk list is mutable, and it can add or 
remove elements at either its beginning or its end, in constant time. Class 
List is a concrete subclass that can be used to instantiate lists. 


Class Array implements an array, which is a sequence whose elements can 
be accessed in constant time—but which cannot grow or shrink. Although 
class Array inherits from SequenceableCollection and therefore indirectly 
from Collection, it does not implement the full collection protocol: it im- 
plements only those methods that can be implemented without growing or 
shrinking. Class Array is a concrete subclass that can be used to instantiate 
arrays. 


The collection protocols are described in detail in Figures 10.14 (class protocol) 
and 10.15 (instance protocol). 


* Each collection class responds to a with: message, which creates a collec- 
tion containing a single element, and to a withAl1: message, which creates 
a collection that contains all the elements from another collection. 


The instance methods in the first group are mutators; they define ways of 
adding and removing elements. In Smalltalk, a mutator typically answers 
the receiver, which makes it easy to send several mutation messages to the 
same object in sequence. 


The instance methods in the second group are observers; they define ways 
of finding out about the elements in a collection. The includes: and 
occurrencesOf: observers ask about elements directly; the detect: and 
detect:ifNone: observers ask for any element satisfying a given predicate, 
which is typically represented as a block. The = observer asks if two collec- 
tions contain the same objects (according to =). 
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add: newObject Include the argument, newObject, as one of the 
elements of the receiver. Answer the receiver. 


addAll: aCollection Add every element of the argument to the 
receiver; answer the receiver. 


remove: oldObject Remove the argument, oldObject, from the 
receiver. If no element is equal to oldObject, 
report an error; otherwise, answer the receiver. 


remove:ifAbsent: oldObject exnBlock 
Remove the argument, oldObject, from the 
receiver. If no element is equal to oldObject, 
answer the result of evaluating exnBlock; 
otherwise, answer the receiver. 


removeAll: aCollection Remove every element of the argument from the 
receiver; answer the receiver or report an error. 


isEmpty Answer whether the receiver has any elements. 
size Answer how many elements the receiver has. 
includes: anObject Answer whether the receiver has anObject. 


occurrencesOf: anObject Answer how many of the receiver’s elements are 
equal to anObject. 


detect: aBlock Answer the first element x in the receiver for 
which (aBlock value: x) is true, or report an 
error if none. 


detect:ifNone: aBlock exnBlock 
Answer the first element x in the receiver for 
which (aBlock value: x) is true, or answer 
(exnBlock value) if none. 


= aCollection Answer whether the contents of the receiver are 
equivalent to the contents of the argument. 


do: aBlock For each element x of the collection, evaluate 
(aBlock value: x). 


inject:into: aValue binaryBlock 
Evaluate binaryBlock once for each element in 
the receiver. The first argument of the block is 
an element from the receiver; the second 
argument is the result of the previous evaluation 
of the block, starting with aValue. Answer the 
final value of the block. 


select: aBlock Answer a new collection like the receiver, 
containing every element x of the receiver for 
which (aBlock value: x) is true. 


reject: aBlock Answer a new collection like the receiver, 
containing every element x of the receiver for 
which (aBlock value: x) is false. 


collect: aBlock Answer a new collection like the receiver, 
containing (aBlock value: x) for every 
element x of the receiver. 


Figure 10.15: Public instance protocol for Collection 


* The instance methods do: and inject:into: are iterators. An iterator is a 
special kind of observer that repeats a computation once for every element 
in a collection. The do: method performs a computation only for side effect, 
while inject:into: accumulates and answers a value. These two methods 
correspond to the wScheme functions app and fold1, but they are defined on 
all collections, not only on lists. 


* The instance methods in the final group are producers; given a collection, $10.4 
a producer makes a new collection without mutating the original. Methods The initial basis 
select: andcollect: correspond tothe Scheme functions filter andmap, of Smalltalk 
which are also defined in ML. 645 


Collection is an abstract class, so a client should not send a new, with:, or 
withA11: message directly to Collection—only to one of its concrete subclasses. 

The simplest subclass of Collection is Set; to get a feel for sets and for the 
Collection protocol, look at this transcript: 


645a. (transcript 611a) += <1640b 645b> 
-> (val s (Set new)) 
Set( ) 
-> (s size) 
0 
-> (s add: 2) 
Set( 2 ) 
-> (s add: ‘abc) 
Set( 2 abc ) 
-> (s includes: 2) 
<True> 
-> (s add: 2) 
Set( 2 abc ) 


Remember that when a message is sent to a receiver, the method has access not 
only to the values of the arguments but also to the receiver. For example, the add: 
method takes only one argument, the item to be added, but it also has access to the 
collection to which the item is added. 
Collection methods can operate on collections of mixed kinds. For example, 

I build a set s from an array, and then I use the set’s addAl11: method to add the 
elements of another array. 
645b. (transcript 611a) += <1645a 645c> 

-> (set s (Set withAll: '(1 2 3 1 2 3))) 

Set( 123 ) 

-> (s addAll: '(12 3 abcde f)) 

Set( 12 3abcdef ) 

-> (Ss includes: 'b) 

<True> 


Number B 663 


This kind of mixed computation, where I pass an array as an argument to a set op- Bes Baca 


eration, is not possible using abstract data types. But using objects, it’s easy: the 
addAll: method treats the argument object abstractly. As long as the argument 
responds to the Collection protocol, addAll: doesn’t care what class it’s an in- 
stance of. The addAl1: method interacts with the argument only by sending it the 
do: message. 
Other messages that work with any collection include removeAll: andreject:. 

645¢. (transcript 611a) += <1645b 648D 

-> (s removeAll: '(e f)) 

Set( 12 3 abcd ) 

-> (val s2 (s reject: [block (x) (x isKindOf: Number)])) 

Set( abcd ) 
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Object-orientation also provides an effortless form of polymorphism. In the 
example, set s is initialized by sending Set the withAll: message with array ar- 
gument '(1 23 123), which contains duplicate elements. The implementation of 
withA11:, which is shared by multiple collection classes, eliminates the duplicates. 
It identifies duplicates by sending the = message to individual elements. Because 
the = message is dispatched dynamically, it automatically has the right semantics 
for comparing elements, no matter what classes the elements are instances of. 
In Scheme, by contrast, getting equality right requires either passing an equality 
function as a parameter, storing it in a data structure, or capturing it in a closure 
(Section 2.9, page 131). But in Smalltalk, as in every object-oriented language, an 
object already acts like a closure—it is data bundled with code—and the bundle in- 
cludes the right version of =. No additional coding is required. 


Keyed collections and class Dictionary 


KeyedCollectionis another abstract class; the abstraction is a set of key-value pairs 
in which no key occurs more than once. This abstraction is one of the most fre- 
quently used abstractions in computing, and it has many names: depending on 
context, it may be called an “associative array,’ a “dictionary,” a “finite map,” or 
a “table.” In Smalltalk, “keyed collections” include not only general-purpose key- 
value data structures but also special-purpose structures, including lists and arrays. 

An object of class KeyedCollection responds to the Collection protocol as if 
it were a simple collection of values, with no keys. But KeyedCollection adds new 
messages that can present a key and use it to look up, change, or remove the cor- 
responding value (Figure 10.16, on the next page). 


* The at:put: message updates the receiver; (kc at:put: key value) modi- 
fies collection kc by associating value with key. 


* The observers at: and keyAtValue: answer the value associated with a key 
or the key associated with a value. The observer at: ifAbsent: can be used 
to learn whether a given key is in the collection. (To learn whether a given 
value is in a collection, use the observer includes: from the Collection pro- 
tocol.) Each of these observers works with a key that is equivalent to the key 
originally used with at : put :—identical keys are not needed. 


* The observer associationAt: and the iterator associationsDo: provide ac- 
cess to the key-value pairs directly, in the form of Association objects (Fig- 
ure 10.17). 


+ Mutators removeKey: and removeKey:ifAbsent: can remove a key-value 
pair by presenting an equivalent key. 


Observer at: and mutator at:put: are the most frequently used of the new mes- 
sages. Old messages size, isEmpty, and includes: are also used frequently. 

KeyedCollection is an abstract class; a client should create instances of sub- 
classes only. Its simplest subclass is Dictionary, which represents a collection asa 
list of associations. Class Dictionary assumes only that its keys respond correctly 
to the = message. A more efficient subclass might assume that keys respond to a 
hash message or a comparison message, which would enable it to use a hash table 
or a search tree (Exercises 28 and 29). 


at:put: key value Modify the receiver by associating key 
with value. (May add a new value or 
replace an existing value.) Answer the 
receiver. 


removeKey: key Modify the receiver by removing key 
and its associated value. If key is not in 
the receiver, report an error; otherwise, 
answer the value associated with key. 


removeKey:ifAbsent: key aBlock Modify the receiver by removing key 
and its associated value. If key is not in 
the receiver, answer the result of 
sending value to aBlock; otherwise, 
answer the value associated with key. 


at: key Answer the value associated with key, or 
if there is no such value, report an error. 


at:ifAbsent: key aBlock Answer the value associated with key, 
or the result of evaluating aBlock if 
there is no such value. 


includesKey: key Answer true if there is some value 
associated with key, or false otherwise. 


keyAtValue: value Answer the key associated with value, 
or if there is no such value, report an 
error. 

keyAtValue:ifAbsent: value aBlock 
Answer the key associated with value, 
or if there is no such value, answer the 
result of evaluating aBlock. 


associationAt: key Answer the Association in the 
collection with key key, or if there is no 
such Association, report an error. 


associationAt:ifAbsent: key exnBlock 
Answer the Association in the 
collection with key key, or if there is no 
such Association, answer the result of 
evaluating exnBlock. 


associationsDo: aBlock Iterate over all Associations in the 
collection, evaluating aBlock with each 
one. 


Figure 10.16: New instance protocol for keyed collections (KeyedCollection) 
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Create a new association with the given 
key and value. 


withKey:value: key value 


(a) Class protocol for Association 


key Answer the receiver's key. 
value Answer the receiver’s value. 


setKey: key Set the receiver's key to key. 
y 


setValue: value Set the receiver's value to value. 


(b) Instance protocol for Association 


Figure 10.17: Protocols for associations 


first Answer the first element of the receiver. 

firstkey Answer the integer key that is associated with the first value of the 
receiver. 

last Answer the last element of the receiver. 

lastKey | Answer the integer key that is associated with the last value of the 
receiver. 


Figure 10.18: New instance protocol for sequenceable collections 


Sequenceable collections 


The abstract class SequenceableCollection represents a keyed collection whose 
keys are consecutive integers—in other words, a sequence. Such acollection under- 
stands additional messages: firstKey and lastKey answer the first and last keys, 
and first and last answer the first and last values (Figure 10.18). 


Lists A List is a sequence that can change size: an element can be added or 
removed at either end (Figure 10.19, on the next page). Unlike a Scheme list, a 
Smalltalk list is mutable: adding or removing an element mutates the original list, 
rather than creating a new one. The add: message is a synonym for addLast:. 

Lists are illustrated by this transcript: 
648. (transcript 611a) += <1645¢ 652a> 
-> (val xs (List new)) 


List( ) 

-> (xs addLast: 'a) 
List( a ) 

-> (xs add: 'b) 
List( ab ) 


-> (xs addFirst: 'z) 
List( zab ) 

-> (xs first) 

z 

-> (xs addFirst: 'y) 
List( yzab ) 

-> (xs at: 2) 

a 

-> (xs removeFirst) 
y 

-> xs 

List( zab ) 


addLast: anObject Add anObject to the end of the receiver and answer 
the receiver. 


addFirst: anObject Add anObject to the beginning of the receiver and 
answer the receiver. 


removeFirst Remove the first object from the receiver and answer 


that object. Causes an error if the receiver is empty. 
§10.4 
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removeLast Remove the last object from the receiver and answer 
that object. Causes an error if the receiver is empty. 


Figure 10.19: New instance protocol for lists (List) 649 


Arrays An array is a sequence that cannot change size, but that implements at: 
and at:put: in constant time. Arrays are found in many programming languages; 
in Smalltalk, every array is one-dimensional, and the first element’s key is 0. 
(In Smalltalk-80, the first element’s key is 1.) 

An instance of Array responds to the messages of the SequenceableCollection 
protocol. (Because an array cannot change size, it responds to add: and remove: 
with errors.) The Array class responds to the messages of the Sequenceable- 
Collection class protocol, and also to message new:, which expects a size: 


new: anInteger Create and answer an array of size anInteger in which 
each element is nil. 


Inheriting from Collection 


To define a new subclass of Collection might seem like an enormous job; after all, 
Figure 10.15 shows a great many messages, an instance of any subclass must un- 
derstand. But the Collection class is carefully structured so that a subclass need 
implement only four of the methods in Figure 10.15: do:, to iterate over elements, 
add:, to add an element, remove: ifAbsent:, to remove an element, and =, to com- 
pare contents. The details appear in Section 10.7.1. 


10.4.6 Magnitudes and numbers 


Collections make up a large part of wSmalltalk’s initial basis. Much of the rest of 
the basis deals with numbers. The numeric classes illustrate the same inheritance 
techniques as the collection classes: each concrete subclass defines a minimal set 
of representation-specific methods like +, *, and negated, and they all share inher- 
ited implementations of generic methods like -, isNegative, and abs. The most 
important numeric classes fit into this hierarchy: 


. add: B 644 
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Magnitude 


Number 


- i a 


Fraction Float Integer 


On page 651, this hierarchy is extended with large integers. 

Class Magnitude supports comparisons, as well as min: and max: operations. 
The Magnitude protocol can be implemented by any totally ordered abstraction, 
like a number, a date, or a time. Magnitudes can be used in the implementations 
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= aMagnitude 
< aMagnitude 


> aMagnitude 


<= aMagnitude 


>= aMagnitude 


min: aMagnitude 


max: aMagnitude 


Answer whether the receiver equals the argument. 
Answer whether the receiver is less than the argument. 


Answer whether the receiver is greater than the 
argument. 


Answer whether the receiver is no greater than the 
argument. 


Answer whether the receiver is no less than the 
argument. 


Answer the lesser of the receiver and aMagnitude. 


Answer the greater of the receiver and aMagnitude. 


(a) Instance protocol for Magnitude 


negated Answer the negation of the receiver (“unary minus”). 

reciprocal Answer the reciprocal of the receiver. 

abs Answer the absolute value of the receiver. 

+ aNumber Answer the sum of the receiver and the argument. 

- aNumber Answer the difference of the receiver and the 
argument. 

* aNumber Answer the product of the receiver and the argument. 

/ aNumber Answer the quotient of the receiver and the argument. 
The quotient is not rounded to the nearest integer, so 
the quotient of two integers may be a fraction. 

isNegative Answer whether the receiver is negative. 

isNonnegative Answer whether the receiver is nonnegative. 

isStrictlyPositive Answer whether the receiver is positive (> 0). 
(The “strictly” is from Smalltalk-80, which inexplicably 
uses “positive” to mean > 0.) 

isZero Answer whether the receiver is zero. 


raisedToInteger: anInteger 


squared 


sqrtWithin: eps 


sqrt 


Answer the receiver, raised to the integer power 
anInteger. 


Answer the receiver squared. 


Answer a number that is within eps of the square root 
of the receiver. 


Answer the square root of the receiver, to within some 
eps defined by the implementation. 


coerce: aNumber 


asInteger 
asFraction 


asFloat 


Answer a Number that is of the same kind as the receiver, 
but represents the same value as the argument. 


Answer the integer nearest to the value of the receiver. 
Answer the fraction nearest to the value of the receiver. 


Answer the floating-point number nearest to the value 
of the receiver. 


(b) Instance protocol for Number 


Figure 10.20: Protocols for magnitudes and numbers 


div: anInteger Answer the integer quotient of the receiver and the 
argument, rounding towards —oo. 


mod: anInteger Answer the modulus of the receiver and the 
argument, with division rounding towards —oo. 


gcd: anInteger Answer the greatest common denominator of the 
receiver and the argument. 


lcm: anInteger Answer the least common multiple of the receiver 
and the argument. 


timesRepeat: aBlock Ifthe receiver is the integer n, send value to aBlock 
nm times. 


Figure 10.21: New instance protocol for integers 


of search trees, sorted collections, and so on. Class Number supports not only com- 
parisons but also arithmetic, plus other operations that can be performed only on 
numbers: a Number can be asked about its sign; it can be asked for a power, square, 
or square root; and it can be coerced (converted) to be an integer, a fraction, or a 
floating-point number. Protocols for both Magnitude and Number are shown in Fig- 
ure 10.20 (on the facing page). 

In Smalltalk-80, the predefined magnitudes include dates, times, and charac- 
ters; in Smalltalk, the predefined magnitudes include only natural numbers and 
the Number classes. Other magnitudes can be defined (Exercise 33). jSmalltalk’s 
predefined numbers are more interesting: objects of class Integer represent inte- 
gers, and instances of Fraction and Float represent rational numbers. A Fraction 
represents a rational number as the ratio of numerator n to denominator d. AFloat 
represents a rational number of the form m - 10°, where m is an integer mantissa 
and e is an integer exponent. 

These predefined numeric classes support all of the arithmetic and comparison 
operations in the Magnitude and Number protocols, but they support only homoge- 
neous operations: for example, integers can be compared only with integers, frac- 
tions only with fractions, and floating-point numbers only with floating-point num- 
bers. The same goes for addition, subtraction, multiplication, and so on. For ex- 
ample, the fraction 3/4 can’t be asked if it is less than the integer 1—and yet, such 
questions are both convenient and in the spirit of object-oriented programming. 
Fortunately, mixed comparisons and arithmetic are not hard to implement (Exer- 
cise 36). 


Integers Integers provide not just the standard arithmetic operations expected of 
all numbers, but also div:, mod:, gcd:, and 1cm:, which are defined only on inte- 
gers. And an integer n can be told to evaluate a block n times. In pzSmalltalk, in- 
tegers come in two forms: small integers, which I implement, and large integers, 
which I invite you to implement (Exercise 38). The integer subhierarchy looks like 
this: 


Integer 


re a 


SmalliInteger LargeInteger 


Be nas 


LargePositiveInteger LargeNegativeInteger 


These classes are discussed in Section 10.8.3 (page 667), and they all answer the 
protocol shown in Figure 10.21. 
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Fractions A Fraction represents a rational number as a fraction. For example, 
in the session below, sending (two sqrtWithin: epsilon) answers oe which ap- 
proximates \/2 to within epsilon (+). The approximation, 1.416, is quite close to 
the actual value of 1.4142+. 
652a. (transcript 611a) += <1648 652b> 

-> (val two (Fraction num:den: 2 1)) 

-> (val epsilon (Fraction num:den: 1 10)) 

1/10 

-> (val root2 (two sqrtWithin: epsilon) ) 

17/12 


Better precision can be had by decreasing epsilon. And fractions can be com- 
puted conveniently and idiomatically by dividing integers or by using asFraction. 
652b. (transcript 611a) += 1652a 652c> 

-> (val epsilon (1 / 100)) 

1/100 

-> (val root2 ((2 asFraction) sqrtWithin: epsilon)) 
577/408 


The square root of n is computed by using the Newton-Raphson technique for find- 
ing a zero of the function x? — n. Newton-Raphson produces accurate results 
577 


quickly; the approximation 753 is accurate to five decimal places. 


Floating-point numbers A number in floating-point form is represented by a man- 
tissa m and exponent e, which stand for the number m - 10°. Both m and e can 
be negative. A Float satisfies the representation invariant that |m| < 32767; this 
restriction, which provides about 15 bits of precision, ensures that two mantissas 
can be multiplied without arithmetic overflow. 
Class Float can be used as follows: 

652c. (transcript 611a) += <1652b 

-> (val epsilon ((1 / 100) asFloat)) 

1x10A-2 

-> ((2 asFloat) sqrtWithin: epsilon) 

14142x10A-4 


The result is good to five decimal places. 


10.4.7. Natural numbers 


Anatural number is more than a magnitude but less than a full Number: jSmalltalk’s 
class Natural supports limited arithmetic and a couple of new observers. A natu- 
ral number is a form of magnitude, and class Natural is a subclass of Magnitude. 
In addition to the protocol for Magnitude, including comparisons, class Natural 
and its instances respond to the protocol in Figure 10.22 on the next page. 

Natural numbers may be added and multiplied without fear of overflow—the 
size of a natural number is limited only by the amount of memory available. Natu- 
ral numbers may also be subtracted, provided that the argument is no greater than 
the receiver. And a natural number may be divided by a small, positive integer; 
the s in sdiv: and smod: stands for “short.” (As noted on page S19, long division is 
beyond the scope of this book.) 

The protocol for instances of Natural includes an observer decimal, which con- 
verts the receiver to a list of decimal digits. (For efficiency, the receiver is expected 
to use an internal representation with a base much larger than 10.) 


fromSmall: anInteger Answer a natural-number object whose value is 
equal to the value of the argument, which must be a 
nonnegative integer. 


(a) Class protocol for Natural 


+ aNatural Answer the sum of the receiver and the argument. 
: 10.4 
* aNatural Answer the product of the receiver and the argument. AS ‘ . 
The initial basis 
- aNatural Answer the difference of the receiver and the of Smalltalk 
argument, or if this difference is not a natural 
number, fail with a run-time error. 653 


sdiv: aSmallInteger Answer the largest natural number whose value is at 
most the quotient of the receiver and the argument. 


smod: aSmallInteger Answer a small integer that is the remainder when 
the receiver is divided by the argument. 


decimal Answer a List containing the decimal digits of the 
receiver, most significant digit first. 


sdivmod:with: aSmallInteger aBlock 
An object n receiving (n sdivmod:with: d 6) 
answers the result of sending (b value: value: Qr), 
where @ is n div dand ris n mod d. 


subtract: withDifference:ifNegative: aNatural diffBlock negBlock 
Subtract aNatural from the receiver to obtain 
difference d. If the difference is a natural number, 
answer (diffBlock value: d). If the difference is 
negative, answer (negBlock value). 


isZero If the receiver is zero, answer true; otherwise 
answer false. 


(b) Instance protocol for natural numbers 


Figure 10.22: Protocols for natural numbers 


Finally, the Natural protocol includes three methods that are intended to pro- 
mote efficiency: 


* Method sdivmod: with: computes both quotient and remainder in a single 


2 ‘ ; : Pudi: ae wat J asFloat 6650 
operation. It is necessary in order to implement division in linear time. If a 


ae asFraction 
division operation were to send both sdiv: and smod:, division could take B 650 
time exponential in the number of digits, which is not acceptable. Fraction B 664 
sqrtWithin: 
* Method subtract: withDifference:ifNegative: combines comparison and B 650 


subtraction into a single operation. Implemented independently, each of 
these operations could take linear time, and comparison comes “for free” 
with a subtraction. 


* Method isZero can sometimes be implemented more efficiently than =. 


The implementation of class Natural is left to you (Exercise 37). Ideas are pre- 
sented on page 669. 
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10.5 OBJECT-ORIENTED PROGRAMMING TECHNIQUES 


To get started programming in Smalltalk, you can focus on the examples from Sec- 
tion 10.1 and on the protocols and informal descriptions of the predefined classes in 
Section 10.4. But to internalize object-oriented ways of thinking and programming, 
you need to study more deeply. Four increasingly deep techniques are presented 
in the next four sections: 


* Section 10.6 shows how to make decisions by dispatching messages to the 
right methods, not by evaluating conditionals. The technique is illustrated 
with example methods defined on classes Object, UndefinedObject, and 
Boolean. 


Section 10.7 shows how to reuse code by building abstract classes that pro- 
vide many useful methods on top of just a few subclass responsibilities. 
The technique is illustrated with example methods defined on collection 
classes. 


Section 10.8 shows how to define methods that want to look at representa- 
tions of more than one object, even though a method defined on an object 
has access only to its own instance variables. The technique is illustrated 
with example methods defined on numeric classes. 


Section 10.9 shows how to integrate ideas from Sections 10.6 and 10.7 with 
program-design ideas from Chapter 9, including an abstraction function and 
representation invariant. The techniques are illustrated with a complete im- 
plementation of class List. 


10.6 TECHNIQUE I: METHOD DISPATCH REPLACES CONDITIONALS 


An object-oriented program differs most from a functional or procedural program 
in the way it makes decisions. An object-oriented program doesn’t ask an object, 
“How were you formed?” Instead, it sends a message that asks a different question 
or makes a request. The form of the receiver becomes known not by evaluating an 
expression but by dispatching to a method. For example, we can ask any object, 
“Are you nil?” by sending it message isNil or notNil. Methods isNil and notNil 
are defined in ordinary Smalltalk, on classes Object and UndefinedObject. Be- 
fore we study the definitions, here’s how not to do it—two ways to test for nil by 
evaluating an expression: 


(method isNil () (self == nil)) ; embarrassing 
(method isNil () (self isMemberOf: UndefinedObject)) ; more embarrassing 


This code makes a real Smalltalk programmer cringe. In Smalltalk, case analysis 
should be implemented by method dispatch. For isNil there are only two possi- 
ble cases: an object is nil or it isn’t. I arrange that on the nil object, the isNil 
method answers true, and that on all other objects, it answers false. I need only 
two method definitions: one on class UndefinedObject, which is used only to an- 
swer messages sent to nil, and one on class Object, which all other classes inherit. 
I implement notNil the same way. The definitions on class UndefinedObject are 

654. (methods of class UndefinedObject 654)= $559d> 


(method isNil () true) 7; definitions on UndefinedObject 
(method notNil () false) 


On class Object, they are 
655a. (methods of class Object 634) += <1635a S558c> 
(method isNil () false) ;; definitions on Object 
(method notNil () true) 
The definitions contain no conditionals; decisions are made entirely by method 
dispatch. For example, when isNil is sent to nil, nil is an instance of class 
UndefinedObject, so the message dispatches to UndefinedObject’s isNil method, 
which answers true. But when isNil is sent to any other object, method search 
starts in the class of that object and eventually reaches class Object, where it dis- 
patches to Object’s isNil method, which answers false. A notNil message works 
the same way. 

If you take object-oriented programming seriously, you will never use an explicit 
conditional if you can achieve the same effect using method dispatch. Method dispatch 
is preferred because it is extensible: to add new cases, you just add new classes— 
think, for example, about adding new kinds of shapes to the pictures in Section 10.1. 
To add new cases toa conditional, you would have to edit the code—at every location 
where a similar conditional decision is made. Method dispatch makes it easier to 
evolve the code. And in many implementations, it is also more efficient. 

Some conditionals can’t be avoided. For example, to know if a number n is 
at least 10, we must send a conditional message like ifTrue: to the Boolean ob- 
ject produced by (n >= 10). But ifTrue: is itself implemented using method dis- 
patch! Smalltalk’s conditionals and loops aren’t written using syntactic forms like 
pScheme’s if and while, because Smalltalk has no such forms—it has only mes- 
sage passing and return. Conditionals are implemented by sending continuations 
to Boolean objects, and loops are implemented by sending continuations to block 
objects.?° 

A conditional method like ifTrue: is implemented in both of the subclasses of 
Boolean: True and False. By the time a method is activated, the conditional deci- 
sion has already been made by method dispatch; the method has only to take the 
action appropriate to the subclass it is defined on. Each subclass defines methods 
according to what its instance represents; for example, class True has one instance, 
true, which represents truth, and its methods are defined accordingly: 
655b. (predefined Smalltalk classes and values 655b) = $548d> 

(class True 
[subclass-of Boolean] 
(method ifTrue: (trueBlock) (trueBlock value)) 
(method ifFalse: (falseBlock) nil) 
(method ifTrue:ifFalse: (trueBlock falseBlock) (trueBlock value) ) 
(method ifFalse:ifTrue: (falseBlock trueBlock) (trueBlock value) ) 


(method not () false) 

(method & (aBoolean) aBoolean) 
(method | (aBoolean) self) 

(method eqv: (aBoolean) aBoolean) 
(method xor: (aBoolean) (aBoolean not)) 


(method and: (alternativeBlock) (alternativeBlock value) ) 
(method or: (alternativeBlock) self) 
) 
The implementation of class False, which is similar, is left as Exercise 16. The in- 
genious division of class Boolean into subclasses True and False is owed to Dan 
Ingalls (2020). 


l0This implementation of conditionals is the same one used in the Church encoding of Booleans in the 
lambda calculus—a tool used in the theoretical study of programming languages. 
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10.7 TECHNIQUE II: ABSTRACT CLASSES 


Object-oriented code can achieve a form of polymorphism not readily available in 
languages like Scheme and ML: By relying on subclass responsibilities, methods 
like min: and max: (for magnitudes) or detect: and select: (for collections) can 
be implemented once and reused by many different subclasses. Such reuse is il- 
lustrated below with examples from magnitudes and collections. The collection 
example is then developed further by showing how subclasses for keyed and se- 
quenceable collections refine and extend the Collection protocol. This is a great 
technique to emulate in your own designs. 


10.7.1 Implementing wide protocols: Magnitudes and collections 


The Magnitude protocol suits any abstraction that is totally ordered, even those 
that do not support arithmetic: numbers, dates, times, and so on. A subclass of 
Magnitude has only two responsibilities: comparisons = and <.!" 
656a. (numeric classes 656a) = (S548d) 664a> 
(class Magnitude 

[subclass-of Object] ; abstract class 

(method = (x) (self subclassResponsibility)) ; may not inherit 

(method < (x) (self subclassResponsibility) ) 

(other methods of class Magnitude 656b) 


) 


The other comparisons, as well as min: and max:, are implemented using <, and 
they can be reused in every subclass. 
656b. (other methods of class Magnitude 656b) = (656a) 
(method > (Cy) (y < self)) 
(method <= (x) ((self > x) not)) 
(method >= (x) ((self < x) not)) 
(method min: (aMagnitude) 
((self < aMagnitude) ifTrue:ifFalse: {self% faMagnitude?)) 
(method max: (aMagnitude) 
((self > aMagnitude) ifTrue:ifFalse: {self% faMagnitude?)) 


Another big protocol that relies on just a few subclass responsibilities is the 
Collection protocol. This protocol is a joy to work with; it includes not only object- 
oriented analogs to functions like exists?, map, filter, and fold1, but also many 
other methods, which do things like add, remove, find, and count elements (Fig- 
ure 10.15, page 644). And unlike their Scheme analogs, these operations support 
not only lists but also several other forms of collection. All this functionality is 
provided using just four subclass responsibilities: a collection class must define 
methods do:, add:, remove: ifAbsent:, and =. 
656c. (collection classes 656c) = (S548d) 659ap 

(class Collection 

[subclass-of Object] ; abstract 
(method do: (aBlock) (self subclassResponsibility)) 
(method add: (newObject) (self subclassResponsibility) ) 
(method remove:ifAbsent: (oldObject exnBlock) 

(self subclassResponsibility)) 
(method = (aCollection) (self subclassResponsibility)) 
(other methods of class Collection 657a) 


) 
To see how these subclass responsibilities are implemented, look at class Set (Ap- 
pendix U, page S562). To see how the subclass responsibilities are used, look below. 


1 According to the rules of Smalltalk, a magnitude may not inherit the default implementation of = 
from class Object, which is object identity. That’s why method = is redefined as a subclass responsibility. 


To create a singleton collection, we send add: to a new instance; to create a col- 
lection holding all of an argument’s elements, we send addA11: to a new instance. 
657a. (other methods of class Collection 657a)= (656c) 657b> 

(class-method with: (anObject) 
((self new) add: anObject)) 
(class-method withAll: (aCollection) 
((self new) addAll: aCollection)) 


When addA1l1: is sent to an object of a subclass, the message dispatches to the 
method shown here, which is defined on class Collection. Itis implemented using 
do: and add:. 
657b. (other methods of class Collection 657a) += (656c) 1657a 657¢> 

(method addAll: (aCollection) 
(aCollection do: [block (x) (self add: x)]) 
self) 


When method addA11: sends do: and add:, they dispatch to the methods defined 
on the subclass. 
Removal works in the same way, building on do: and remove: ifAbsent:. 
657c. (other methods of class Collection 657a) += (656c) 1657b 657d> 
(method remove: (oldObject) 
(self remove:ifAbsent: oldObject {(self error: 'remove-was-absent) ?)) 
(method removeAll: (aCollection) 
(aCollection do: [block (x) (self remove: x)]) 
self) 


In addition to these mutators, the Collection protocol defines a host of ob- 
servers, including isEmpty and size, among others (page 644). The default imple- 
mentations given here iterate through the elements of the collection using do:. 


657d. (other methods of class Collection 657a) += (656c) <657c¢ 657e> 
(method size () [locals n] 
(set n 0) 
(self do: [block (_) (set n (n + 1))]) 
n) 
(method occurrencesOf: (anObject) [locals n] 
(set n Q) 
(self do: [block (x) ((x = anObject) ifTrue: (set n (n + 1))3)]) 
n) 


Using a linear search to compute size, for example, may seem inefficient, but if 
a subclass knows a more efficient way to compute the number of elements, it re- 
defines the size method. And for some collections, like List, there is no more 
efficient way to compute size or count occurrences. 

An iteration that uses do: can be cut short by a return expression, as in meth- 
ods isEmpty, includes:, and detect:ifNone: below. And again, if the collection 
is a linked list, no more efficient implementation is possible. 


657e. (other methods of class Collection 657a) += (656c) 657d 658a> 
(method isEmpty () 
(self do: [block (_) (return false) ]) 
true) 
(method includes: (anObject) 
(self do: [block (x) ((x = anObject) ifTrue: ¢(return true)?)]) 
false) 
(method detect:ifNone: (aBlock exnBlock) 
(self do: [block (x) ((aBlock value: x) ifTrue: ¢(return x)?)]) 
(exnBlock value)) 
(method detect: (aBlock) 
(self detect:ifNone: aBlock {(self error: 'no-object-detected) ?)) 


§10.7 
Technique II: 
Abstract classes 


657 


Smalltalk and 
object-orientation 


658 


species Answer a class that should be used to create new instances of 
collections like the receiver, to help with the implementation of 
select:, collect:, and similar methods. 


printName Print the name of the object’s class, to help with the 
implementation of print. (Almost all Collection objects print 
as the name of the class, followed by the list of elements in 
parentheses. Array objects omit the name of the class.) 


Figure 10.23: Private methods internal to Collection classes. 


In addition to mutators and observers, the Collection protocol also pro- 
vides iterators. These iterators are akin to wScheme’s higher-order functions on 
lists. For example, do: resembles jsScheme’s app, and inject:into: resembles 
pScheme’s foldl. But as before, objects offer this advantage: unlike jsScheme’s 
foldl, inject:into: works on any collection, not just on lists. 
658a. (other methods of class Collection 657a) += (656c) <1657e 658b> 

(method inject:into: (aValue binaryBlock) 


(self do: [block (x) (set aValue (binaryBlock value:value: x aValue))]) 
aValue) 


The methods select:, reject:,andcollect: resemble wScheme’s filter and 
map functions. Like inject:into:, they work on all collections, not just on lists. 
The implementations use species, which is a private message used to create “a new 
collection like the receiver” (Figure 10.23). 


658b. (other methods of class Collection 657a) += (656c) 658a 658¢> 
(method select: (aBlock) [locals temp] 
(set temp ((self species) new)) 
(self do: [block (x) ((aBlock value: x) ifTrue: ¢(temp add: x)?)]) 
temp) 
(method reject: (aBlock) 
(self select: [block (x) ((aBlock value: x) not)])) 
(method collect: (aBlock) [locals temp] 
(set temp ((self species) new)) 
(self do: [block (x) (temp add: (aBlock value: x))]) 
temp) 


A species defaults to the class of the receiver. 


658c. (other methods of class Collection 657a) += (656c) <1658b 658d> 
(method species () (self class)) 


Finally, Collection defines its own print method. By default, a collection 
prints as the name of its class, followed by a parenthesized list of its elements. 


658d. (other methods of class Collection 657a) += (656c) 1658c 
(method print () 
(self printName) 
(left-round print) 
(self do: [block (x) (space print) (x print)]) 
(space print) 
C(right-round print) 
self) 
(method printName () (((self class) name) print)) 


Both methods may be overridden by subclasses. 


Table 10.24: How protocols are refined for keyed and sequenceable collections 


Implements Passes on Adds Overrides 
y do:,= add, at:put, = 
QS remove:ifAbsent associationsDo:, 
“< removeKey:ifAbsent: 
associationsDo: add, at:put, firstKey, lastKey at: IfAbsent: 
a remove:ifAbsent, 
removeKey:ifAbsent, 
species 


10.7.2 Widening a protocol: Keyed and sequenceable collections 


Collection isn’t just an abstract class with multiple implementations. It’s an ab- 
straction that is refined into more abstractions: 


* Keyed collections, which collect key-value pairs and can be indexed by key 


* Sequenceable collections, which are keyed by consecutive integers 


Each of these collections refines the protocol defined by its superclass. To study 
such refinement, we ask the same questions about each subclass: 


* Which of the subclass responsibilities inherited from the superclass does it 
implement? 


+ What subclass responsibilities inherited from the superclass does it pass on 
to its own subclasses? 


* What new subclass responsibilities does it add? 


* What methods inherited from the superclass does it override? On what 
grounds? 


For keyed and sequenceable collections, the answers are shown in Table 10.24. 


Implementation of KeyedCollection 


A keyed collection provides access to key-value pairs. It must define method 
associationsDo:, which replaces do:, method removeKey:ifAbsent:, which re- 
places remove: ifAbsent:, and method at:put:, which sometimes replaces add:. 
The key-value pairs answer the Association protocol. 
659a. (collection classes 656c) += (S548d) <656c 66la> 
(class KeyedCollection 
[subclass-of Collection] ; abstract class 


(method associationsDo: (aBlock) (self subclassResponsibility)) 
(method removeKey:ifAbsent: (key exnBlock) (self subclassResponsibility) ) 
(method at:put: (key value) (self subclassResponsibility)) 


(other methods of class KeyedCollection 659b) 
) 


The associationsDo: method is used to implement the do: method required 
by the superclass: 


659b. (other methods of class KeyedCollection 659b)= (659a) 660a> 
(method do: (aBlock) 


(self associationsDo: [block (anAssoc) (aBlock value: (anAssoc value))])) 
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Every method in the “at” family, as well as includesKey:, is ultimately imple- 
mented on top of associationAt:ifAbsent:, which uses associationsDo:. 


660a. (other methods of class KeyedCollection 659b) += (659a) 1659b 660b> 
(method at: (key) 
(self at:ifAbsent: key {(self error: 'key-not-found) ?)) 
(method at:ifAbsent: (key exnBlock) 
((self associationAt:ifAbsent: key ¢(return (exnBlock value))?) value)) 
(method includesKey: (key) 
Smalltalk and ((self associationAt:ifAbsent: key £3) notNil)) 
object-orientation (method associationAt: (key) 
(self associationAt:ifAbsent: key {(self error: 'key-not-found)?)) 
(method associationAt:ifAbsent: (key exnBlock) 
(self associationsDo: [block (x) (((x key) = key) ifTrue: {(return x)%)]) 
(exnBlock value)) 


660 


When a key is found, method associationAt:ifAbsent: terminates the search im- 
mediately by evaluating a return expression. This efficiency benefits all the other 
methods. And if a subclass implements associationAt:ifAbsent: in a more effi- 
cient way, the other methods benefit from that, too. 
The key associated with a value is found in the same way as the value associated 
with a key. 
660b. (other methods of class KeyedCollection 659b) += (659a) <1660a 660c> 
(method keyAtValue: (value) 
(self keyAtValue:ifAbsent: value {(self error: 'value-not-found) ?)) 
(method keyAtValue:ifAbsent: (value exnBlock) 
(self associationsDo: [block (x) 
(C(x value) = value) ifTrue: $(return (x key))3)]) 
(exnBlock value) ) 


A key is removed by removeAt :ifAbsent. 


660c. (other methods of class KeyedCollection 659b) += (659a) 1660b 660d> 
(method removeKey: (key) 
(self removeKey:ifAbsent: key $(self error: 'key-not-found)?)) 


The = method can be implemented once on class KeyedCollection, instead of 
separately for dictionaries, lists, and arrays. Two keyed collections are equivalent 
if they have equivalent associations. For efficiency, the code looks first for an asso- 
ciation that’s in the receiver but not in the argument. If it finds one, the collections 
are not equivalent, and it returns false immediately. Otherwise, it just has to con- 
firm that both receiver and argument have the same number of associations—then 
and only then are they equivalent. 


660d. (other methods of class KeyedCollection 659b) += (659a) <1660c 
(method = (collection) 
(self associationsDo: ; look for ‘anAssoc* not in ‘collection* 


[block (anAssoc) 
(CCanAssoc value) != 
(collection at:ifAbsent: (anAssoc key) {(return false) ?)) 
ifTrue: 
{(return false) )]) 
((self size) = (collection size))) 


The classic keyed collection is Dictionary. My implementation, which appears 
in Appendix U (page S564), is a simple list of key-value pairs, just like the env type 
in Chapter 5. Implementations using hash tables or search trees can be explored 
in Exercises 28 and 29. 


Implementation of SequenceableCollection 


The abstract class SequenceableCollection defines methods used by keyed col- 
lections whose keys are consecutive integers. Its concrete, predefined subclasses 
are List and Array. 
661a. (collection classes 656c) += (S548d) <1659a 674aD 
(class SequenceableCollection 
[subclass-of KeyedCollection] ; abstract class 
(method firstKey () (self subclassResponsibility) ) 
(method lastKey () (self subclassResponsibility) ) 
(method last () (self at: (self lastKey))) 
(method first () (self at: (self firstKey))) 
(method at:ifAbsent: (index exnBlock) [locals current] 
(set current (self firstKey)) 
(self do: [block (v) 
(Ccurrent = index) ifTrue: {(return v)?) 
(set current (current + 1))]) 
(exnBlock value)) 
(other methods of class SequenceableCollection 661b) 
) 


Because keys are consecutive integers, method at:ifAbsent: can track the value 
of the key inside a do: loop, without ever allocating an Association. This imple- 
mentation is more efficient than the generic implementation inherited from class 
KeyedCollection. 
Method associationsDo: also loops over consecutive keys. 
661b. (other methods of class SequenceableCollection 661b)= (661a) 
(method associationsDo: (bodyBlock) [locals i last] 
(set i (self firstKey)) 
(set last (self lastKey)) 
({(i <= last)? whileTrue: 
~(bodyBlock value: (Association withKey:value: i (self at: i))) 
(set i (i + 1))3)) 


The implementation of concrete class List is described in detail in Section 10.9. 


10.7.3. Compromising on protocol: Class Array 


Classes KeyedCollection and SequenceableCollection refine the Collection 
protocol, adding new operations. Sometimes, however, a class may want to re- 
move operations from a protocol; it wants to reuse methods defined in a superclass 
while implementing only some of its subclass responsibilities. A classic example 
is a fixed-size array: it is a sequenceable collection, and at: and at: put: take only 
constant time, but after it is allocated, a fixed-size array cannot grow or shrink. 
Asa result, it does not implement subclass responsibilities add:, remove: ifAbsent, 
or removeKey:ifAbsent; sending any of those messages results in a checked run- 
time error. 


661c. (other methods of class Array 661c)= ($565e) 662> 
(method add: (x) (self fixedSizeError)) 
(method remove:ifAbsent: (x b) (self fixedSizeError)) 


(method removeKey:ifAbsent: (x b) (self fixedSizeError)) 
(method fixedSizeError QO (self error: 'arrays-have-fixed-size) ) 
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Because class Array exists to promote efficiency, it overrides many inherited 
methods; in particular, it uses primitives to implement methods size, at:, and 
at:put:. These methods are then used to implement firstKey, lastKey, and do:. 
662. (other methods of class Array 661c) += ($565e) <661c 

(method firstKey () 0) 
(method lastKey () ((self size) - 1)) 
(method do: (aBlock) [locals index] 
(set index (self firstKey)) 
((self size) timesRepeat: 
~(aBlock value: (self at: index)) 
(set index (index + 1))3)) 
Instance methods select: and collect: and class method withAl11: are left as 
Exercises 20 and 21, and the rest of Array is relegated to Appendix U. 


10.8 TECHNIQUE III: MULTIPLE REPRESENTATIONS THE OBJECT-ORIENTED WAY 


Smalltalk’s collection abstractions are relatively easy to implement, in part because 
a typical operation involves only one collection: the receiver. And even an opera- 
tion that takes a collection as argument doesn’t have to look at the argument’s repre- 
sentation; for example, methods addA11: and removeA11: simply use do: to iterate 
over the argument’s elements. But in some other abstractions, like the leftist heap 
from Chapter 9 (page 555), an operation like heap merge does have to look at the 
representation of an argument. Such an operation is called complex (Cook 2009). 
And in a pure object-oriented language like Smalltalk, complex operations are not 
so easy to implement. 

We'll study complex operations on numbers (page 650), which have to look at 
the representations of two numbers. For example, 


* Operation < on fractions needs to look at the numerators and denominators 
of both fractions. 


* Operation * on floating-point numbers needs to look at the mantissas and 
exponents of both numbers. 


In a language that uses abstract data types, like Molecule, complex operations like 
these are easy to implement: if an operation can see the definition of a type, it can 
see the representation of every argument of that type. Butin a pure object-oriented 
language, like Smalltalk, a complex method isn’t so easy to implement: it can see 
only the representation of the receiver, and all it can do with an argument is send 
messages to it. To figure out what messages to send, we have several options: 


+ We can extend the argument’s protocol with new messages that provide ac- 
cess to its representation. This technique is illustrated using classes Number, 
Integer, and especially Fraction (Sections 10.8.1 and 10.8.2). 


* If we don’t know the argument’s representation, we might not know what 
new messages it can respond to. In such a case, we can have the receiver 
send a message to the argument telling the argument what new messages the 
receiver can respond to. This technique, called double dispatch, is illustrated 
using the integer classes (Section 10.8.3). 


* We can coerce one object to have the same representation as another. For ex- 
ample, to add aNumber to a fraction, we can coerce aNumber to a fraction. 


This technique is illustrated using the Fraction and Integer classes (Sec- 
tion 10.8.4). 


All three techniques can work with any representation. To help you integrate them 
into your own programming, I recommend a case study for which there is more 
than one reasonable representation: arithmetic on natural numbers. A natural 
number should be represented as a sequence of digits, and every representation of 
that sequence suggests its own set of new messages that are analogous to the new 
messages defined on class Fraction (Section 10.8.5). 


10.8.1 A context for complex operations: Abstract classes Number and Integer 


Before studying complex operations on fractions, we look at the context in which 
fractions are defined. A fraction is a number, and abstract class Number (Fig- 
ure 10.20 on page 650) defines two groups of subclass responsibilities: arith- 
metic methods (+, *, negated, and reciprocal) and coercion methods (asInteger, 
asFraction, asFloat, and coerce:). 
663a. (definition of class Number 663a)= 
(class Number 
[subclass-of Magnitude] ; abstract class 
trecagp arithmetic 


(method + (aNumber) (self subclassResponsibility)) 
(method * CaNumber) (self subclassResponsibility)) 
(method negated QO (self subclassResponsibility)) 
(method reciprocal () (self subclassResponsibility)) 


+ee4¢0 7 Coercion 


(method asInteger () (self subclassResponsibility)) 
(method asFraction () (self subclassResponsibility)) 
(method asFloat QO (self subclassResponsibility)) 


(method coerce: (aNumber) (self subclassResponsibility)) 
(other methods of class Number 663b) 
) 


Subclasses of Number must also implement subclass responsibilities for magni- 
tudes: methods = and <. Methods =, <, +, *, and coerce: take another Number as 
argument, and all except coerce: turn out to be complex. 

To get a feel for the class, let’s see how subclass responsibilities are used to im- 
plement other parts of the Number protocol (page 650). Arithmetic methods are im- 
plemented on top of subclass arithmetic methods, and sign tests are implemented 
on top of comparison and coercion: 
663b. (other methods of class Number 663b)= (663a) S566b> 

(method - (y) (self + (y negated))) 
(method abs () ((self isNegative) ifTrue:ifFalse: {(self negated)? {selfz)) 
(method / (y) (self * (y reciprocal))) 


(method isZero © (self = (self coerce: 0))) 
(method isNegative © (self < (self coerce: 0))) 
(method isNonnegative QO (self >= (self coerce: 0))) 


(method isStrictlyPositive () (self > (self coerce: 0))) 


The Number protocol also requires methods squared, sqrt, sqrtWithin:, and 
raisedToInteger:, which are relegated to the Supplement. 


§10.8 
Technique III: 
Multiple 
representations the 
object-oriented way 


663 


Smalltalk and 
object-orientation 


664 


Before we get to class Fraction, we should also sketch class Integer, which 
provides the gcd: operation needed to put a fraction in lowest terms. The gcd: 
method is one of the four division-related methods gcd:, lcm:, div:, and mod:. 
Only div: has to be implemented in subclasses. 
664a. (numeric classes 656a) += (S548d) <1656a 664cD 

(class Integer 
[subclass-of Number] ; abstract class 
(method div: (n) (self subclassResponsibility)) 
(method mod: (n) (self - (n * (self div: n)))) 
(method gcd: (n) ((n = (self coerce: 0)) 
ifTrue:ifFalse: {self? §(n gcd: (self mod: n))?)) 
(method lcm: (n) (self * (n div: (self gcd: n)))) 
(other methods of class Integer 664b) 
) 


Class Integer typically has three concrete subclasses: SmallInteger, for inte- 
gers that fit in a machine word (Appendix U); LargePositiveInteger, for arbitrar- 
ily large positive integers; and LargeNegativeInteger, for arbitrarily large neg- 
ative integers (Section 10.8.3). In wSmalltalk, only SmallInteger is defined; the 
other two are meant to be added by you (Exercise 38). 

Class Integer implements the subclass responsibility reciprocal, and it also 
overrides the default / method. Both methods answer fractions, not integers. 
664b. (other methods of class Integer 664b)= (664a) 669b> 

(method reciprocal () (Fraction num:den: 1 self)) 
(method / (aNumber) ((self asFraction) / aNumber)) 


10.8.2 Implementing complex operations: Class Fraction 


A method is complex when it needs to inspect the representation of an argument. 
Iintroduce complex methods using class Fraction, whose representation includes 
a numerator num and denominator den, both of which are integer instance vari- 
ables. 
664c. (numeric classes 656a) += (S548d) <1664a 670D 
(class Fraction 

[subclass-of Number] 

[ivars num den] 

(method print () (num print) ('/ print) (den print) self) 

(other methods of class Fraction 664d) 


) 
This representation stands for the ratio 77°. Such ratios can be compared, added, 
and multiplied only if each method has access to the numerator and denominator 
of its argument, not just its receiver—that is, if the methods are complex. The ac- 
cess is provided by private methods num and den, each of which answers the value 
of the instance variable with which it shares a name. 
664d. (other methods of class Fraction 664d) = (664c) 665a> 

(method num () num) ; private 

(method den () den) j; private 


Methods num and den are used to implement the four complex operations =, <, 
*, and +. Each operation relies on and guarantees these representation invariants: 
1. The denominator is positive. 


2. Ifthe numerator is zero, the denominator is 1. 


3. The numerator and denominator are reduced to lowest terms, that is, their 
only common divisor is 1. 


These invariants imply that two Fraction objects represent the same fraction if 
and only if they have the same numerator and denominator, and they enable the 
following implementations of the comparison methods from class Magnitude: 
665a. (other methods of class Fraction 664d) += (664c) 664d 665b> 
(method = (f) ((num = (f num)) and: {(den = (f den))3)) 
(method < (f) ((num * (f den)) < ((f num) * den))) 


The < method uses the law that 4 < ne if and only ifn-d’ < n’ - d, which holds 
only because d and d’ are positive. And argument f doesn’t have to be an instance of 
class Fraction; it’s enough if f is a number and if it responds sensibly to messages 
num and den. 

Methods = and < rely on the representation invariants. The invariants for any 
given fraction are established by two private methods: method signReduce estab- 
lishes invariant 1, and method divReduce establishes invariants 2 and 3. 


665b. (other methods of class Fraction 664d) += (664c) 1665a 665¢> 
(method signReduce () ; private 
((den isZero) ifTrue: ¢(self error: 'ZeroDivide) ?) 
((den isNegative) ifTrue: 
{(set num (num negated)) (set den (den negated))?%) 
self) 
(method divReduce () [locals temp] ; private 
(Cnum = 0) ifTrue:ifFalse: 
{(set den 1)? 
{(set temp ((num abs) gcd: den)) 
(set num (num div: temp) ) 
(set den (den div: temp) )?) 
self) 


When a new Fraction is created by public class method num: den:, all three invari- 
ants are established by private method initNum:den:. 


665c. (other methods of class Fraction 664d) += (664c) 1665b 665d> 
(class-method num:den: (a b) ((self new) initNum:den: a b)) 
(method setNum:den: (a b) (set num a) (set den b) self) ; private 
(method initNum:den: (a b) ; private 
(self setNum:den: a b) 
(self signReduce) 
(self divReduce)) 


Private method setNum:den: sets the numerator and denominator of a fraction, 
but it does not establish the invariants. It is used in multiplication and addition. 
Multiplication is specified by the law 4- ne = Ue but the right-hand side could 
violate invariant 2 or 3. (Numerator n-n’/ and denominator d-d' can have common 
factors, but d - d’ cannot be negative.) The multiplication method therefore sends 
divReduce to the naive result. 
665d. (other methods of class Fraction 664d) += (664c) 665c¢ 666a> 
(method * (f) 
(C(Fraction new) setNum:den: (num * (f num)) (den * (f den))) divReduce)) 


Addition is specified by the law 7 + me a rea ae The resulting numerator 
and denominator may have common factors, violating invariant 3, but such factors 
are eliminated by divReduce, as in the example 4+4 = + a +. Method divReduce 
also restores invariant 2. In addition, the computation of denominator d- d’ might 


overflow. To make overflow less likely, my code defines temp = lcm(d,d’), puts 
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temp in the denominator, and uses oe and ee as needed. Without this tweak, the 


square-root computations in Section 10.4.6 would overflow. 


666a. (other methods of class Fraction 664d) += (664c) 665d 666b> 
(method + (f) [locals temp] 
(set temp (den lcm: (f den))) 
(((Fraction new) setNum:den: 


CCnum * (temp div: den)) + 
((f num) * (temp div: (f den)))) 
temp) 


divReduce) ) 


Method + is the last of the complex methods. But it’s not the last of the methods 
that rely on or guarantee invariants. For example, reciprocal must not leave a 
negative fraction with a negative denominator. The denominator is given the cor- 
rect sign by sending signReduce to the inverted fraction. (The reciprocal of zero 
cannot be put into reduced form. Nothing can be done about it.) 
666b. (other methods of class Fraction 664d) += (664c) 666a 666c> 

(method reciprocal () 
(((Fraction new) setNum:den: den num) signReduce) ) 


Negation negates the numerator; the invariants are guaranteed to be maintained. 
666c. (other methods of class Fraction 664d) += (664c) <1 666b 666d> 
(method negated () ((Fraction new) setNum:den: (num negated) den)) 
The invariants enable the sign tests to inspect only the receiver's numerator. 
These tests are much more efficient than the versions inherited from Number. 


666d. (other methods of class Fraction 664d) += (664c) 1666c 668a> 
(method isZero () (num isZero)) 
(method isNegative () (num isNegative)) 
(method isNonnegative () (num isNonnegative)) 


(method isStrictlyPositive () (num isStrictlyPositive)) 


Class Fraction must also fulfill subclass responsibilities involving coercion, 
which is the topic of Section 10.8.4 (page 667). 


10.8.3 Interoperation with more than one representation: Double dispatch 


Given methods num and den, fractions can be compared with fractions, added to 
fractions, and so on. Comparison and arithmetic methods can’t see the represen- 
tations of their arguments, but they don’t have to: it’s enough to know that each 
argument responds to messages num and den. But comparison and arithmetic on 
integers are not so easy. 

The difficulty with integers is that Smalltalk supports two forms of integer: 
small and large. A small integer must fit in a machine word; a large integer may be 
arbitrarily large. Both forms must respond to a + message, but the algorithm used 
to implement + depends on what is being added: 


* Iftwo small integers are being added, the algorithm uses primitive addition, 
which ultimately executes a hardware addition instruction. 


* If two large integers are being added, the algorithm adds the digits pairwise, 
with carry digits, as described in Appendix B. 


* Ifa large integer and a small integer are being added, the algorithm coerces 
the small integer to a large integer, then adds the resulting large integers. 


The appropriate algorithm depends on more than just the class of the receiver. 


To select the appropriate algorithm, the + method doesn’t interrogate objects 
to ask about their classes. (The object-oriented motto is, “Don’t ask; tell.”) Instead, 
when a small integer receives a + message, its + method sends another message to 
its argument, saying, “I’m a small integer; add me to yourself.” 


667. (SmallInteger methods revised to use double dispatch 667) = 
(method + (anInteger) (anInteger addSmallIntegerTo: self)) 


The addSmallIntegerTo: method knows that its argument is a small integer, and 
like all methods, it knows what class it’s defined on. This is enough information to 
choose the right algorithm: 


* On asmall integer, the addSmallIntegerTo: method uses a machine primi- 
tive to add self to the argument. 


* Ona large integer, the addSmallIntegerTo: method coerces its argument to 
a large integer, then sends the receiver a + message. 


This technique, by which a complex binary operation is implemented in two mes- 
sage sends instead of one, is called double dispatch. 

The story above glosses over an important fact about large-integer operations: 
a large integer has both a sign and a magnitude, and the algorithm for adding large 
integers depends on the sign. If two integers have the same sign, their magnitudes 
are added, but if they have different signs, their magnitudes are subtracted. As al- 
ways, the + method doesn’t interrogate an integer about its sign; instead, positive 
and negative large integers are instances of different classes, and the + method on 
each class dispatches depending on the sign of the receiver. That means that an 
integer class must support three double-dispatch methods for addition: it can be 
told to add a small integer to itself, to add a large positive integer to itself, or to add 
a large negative integer to itself (Figure 10.25, on the next page). 

Methods + and * invoke the double-dispatch method appropriate to the op- 
eration wanted and the class of the receiver. For example, method + on class 
LargePositivelnteger is defined as follows: 


(method + (anInteger) (anInteger addLargePositiveIntegerTo: self)) 


The rest of Figure 10.25 describes the other methods needed to implement 
arithmetic on large integers. Method magnitude plays the same role for large inte- 
gers that methods num and den play for fractions. And methods sdiv: and smod: 
provide a protocol for dividing a large integer by a small integer. (Division of a large 
integer by another large integer requires long division. Long division is fascinating 
algorithmically, but it’s too hairy to make a good exercise.) 

A starter kit for class LargeInteger is shown in Figure 10.26 (page 669). The 
LargeInteger class is meant to be abstract; do not instantiate it. Instead, de- 
fine subclasses LargePositiveInteger and LargeNegativeInteger, which you 
can then instantiate (Exercise 38). 


10.8.4 Coercion between abstractions in Fraction and Integer 


A binary message like < or + should be sent only when the receiver and the argu- 
ment are compatible. If numbers aren't compatible, they can be made so using co- 
ercion. In Smalltalk, coercion is part of the Number protocol; every number must be 
able to coerce itself to an integer, a floating-point number, ora fraction. A coercion 
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addSmallIntegerTo: aSmallInteger 
Answer the sum of the argument and the receiver. 


addLargePositiveIntegerTo: aLargePositiveInteger 

Answer the sum of the argument and the receiver. 
addLargeNegativeIntegerTo: aLargeNegativeInteger 

Answer the sum of the argument and the receiver. 
multiplyBySmalliInteger: aSmallInteger 

Answer the product of the argument and the receiver. 
multiplyByLargePositivelInteger: aLargePositiveInteger 

Answer the product of the argument and the receiver. 
multiplyByLargeNegativeInteger: aLargeNegativeInteger 

Answer the product of the argument and the receiver. 


(a) Private instance protocol for both large and small integers 


fromSmall: aSmallinteger 
Answer a large integer whose value is equal to the 
value of the argument. 

withMagnitude: aNatural 


Answer an instance of the receiver whose magnitude 
is the given magnitude. 


(b) Class protocol for LargeInteger 


magnitude Answer an object of class Natural that represents the 
absolute value of the receiver. 


sdiv: aSmallInteger Answer the large integer closest to but not greater 
than the quotient of the receiver and the argument. 


smod: aSmallInteger Answer the small integer that is the remainder when 
the receiver is divided by the argument. 


(c) Private instance protocol for large integers only 


Figure 10.25: Private protocols for integers 


method typically uses the public protocol of the classes it is coercing its receiver to, 
like these methods defined on class Fraction: 
668a. (other methods of class Fraction 664d) += (664c) (666d 668b> 
(method asInteger () (num div: den)) 
(method asFloat () CC(num asFloat) / (den asFloat))) 
(method asFraction () self) 


To coerce itself to an integer or a floating-point number, a fraction divides num by 
den. Division may be implemented by the integer-division message div: or (after 
coercing num and den to floating point) by the floating-point division message /. 
To coerce itself to a fraction, a fraction needn't divide at all. 

When their classes aren't known, numbers can still be made compatible by 
sending the coerce: message, which tells the receiver to coerce its argument to 
be like itself. For example, a fraction coerces its argument to a fraction. 
668b. (other methods of class Fraction 664d) += (664c) <668a 

(method coerce: (aNumber) (aNumber asFraction)) 


669a. (large integers 669a)= 
(class LargeInteger 
[subclass-of Integer] 
[ivars magnitude] 


(class-method withMagnitude: (aNatural) §10.8 
((self new) magnitude: aNatural)) Technique III: 
(method magnitude: (aNatural) ; private, for initialization Multiple 
(set magnitude aNatural) representations the 
self) 4 : 
object-oriented way 
(method magnitude () magnitude) 669 


(class-method fromSmall: (anInteger) 
(CanInteger isNegative) ifTrue:ifFalse: 
£((Cself fromSmall: 1) + (self fromSmall: ((anInteger + 1) negated))) 
negated)? 

{((LargePositiveInteger new) magnitude: (Natural fromSmall: anInteger) )%)) 
(method asLargeInteger () self) 
(method isZero () (magnitude isZero)) 
(method = (anInteger) ((self - anInteger) isZero)) 
(method < (anInteger) ((self - anInteger) isNegative)) 


(method div: (_) (self error: 'long-division-not-supported) ) 
(method mod: (_) (self error: 'long-division-not-supported) ) 


(method sdiv: (aSmallInteger) (self leftAsExercise) ) 
(method smod: (aSmalliInteger) (self leftAsExercise) ) 


Figure 10.26: Abstract class LargeInteger 


The coercion methods on classes Float and Integer follow the same structure. 
Class Float is relegated to Appendix U, but the Integer methods are shown here. 
Just as a fraction must know what integer or floating-point operations to use to di- 
vide its numerator by its denominator, an integer must know what fractional or 
floating-point operations to use to represent an integer. In this case, it’s self di- 
vided by 1 and self times a base to the power 0, respectively. 
669b. (other methods of class Integer 664b) += (664a) 1664b 669¢> 

(method asFraction () (Fraction num:den: self 1)) 
(method asFloat © (Float mant:exp: self 0)) 


Just as in class Fraction, the other two methods simply exploit the knowledge that 
the receiver is an integer: 
669c. (other methods of class Integer 664b) += (664a) 1669b S567a> 


(method asInteger () self) 
(method coerce: (aNumber) (aNumber asInteger)) 


10.8.5 Choice of representation: Natural numbers 


Using representations that I have defined, the examples above demonstrate tech- 
niques used to implement complex methods like + and <. The same techniques 
can be applied to a representation that you can define: a representation of natural 
numbers (Exercise 37). To get started, follow the guidance below, which presents 
hints, ideas, and private protocols for two possible representations. 
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670. (numeric classes 656a) += (S548d) <664c S567b> 
(class Natural 
[subclass-of Magnitude] 
; instance variables left as an exercise 


(class-method fromSmall: (anInteger) (self leftAsExercise)) 


(method (aNatural) (self leftAsExercise)) 
(method < (aNatural) (self leftAsExercise)) 


(method + (aNatural) (self leftAsExercise)) 
(method * (aNatural) (self leftAsExercise)) 
(method - (aNatural) 
(self subtract: withDifference:ifNegative: 
aNatural 
[block (x) x] 
{(self error: 'Natural-subtraction-went-negative) %)) 
(method subtract: withDifference:ifNegative: (aNatural diffBlock exnBlock) 
(self leftAsExercise)) 


(method sdiv: (n) (self sdivmod:with: n [block (q r) q])) 
(method smod: (n) (self sdivmod:with: n [block (q r) r])) 
(method sdivmod:with: (n aBlock) (self leftAsExercise) ) 


(method decimal () (self leftAsExercise) ) 
(method isZero () (self leftAsExercise) ) 


(method print () (C(self decimal) do: [block (x) (x print)])) 


Figure 10.27: Template for a definition of class Natural 


For efficiency, a natural number should be represented as a sequence of digits 
in some base b (Appendix B). The sequence may reasonably be represented as an 
array or as alist. Smalltalk’s Array class works fine here, but the predefined List 
class does not; you are better off defining empty and nonempty lists of digits as 
subclasses of class Natural. For this reason, I refer to the two representations as 
the “array representation” and the “subclass representation.” Each representation 
calls for its own private protocol to be used to implement the complex methods. 
And both can start with the template in Figure 10.27. 


Natural numbers: The array representation 


If a natural number is represented using an array of digits, I recommend giving it 
two instance variables: degree and digits. The representation invariant should 
be as follows: digits should be an array containing at least degree + 1 integers, 
each of which lies in the range 0 < x; < 6, where bis the base. If digits contains 
coefficients x;, where 0 < 2 < degree, then the abstraction function says that the 
object represents natural number X , where 


degree 


X= a va: b’. 
i=0 


With this array representation, I recommend the private protocol shown in Fig- 
ure 10.28 on the next page. 


base Answers b. 


(a) Private class method for class Natural 


digit: anIndex Upon receiving digit: 2, answer x;. Should 
work for any nonnegative 7, no matter how 
large. 


digit:put: anIndex aDigit On receiving digit:put: 2 y, mutate the 
receiver, making x; = y. Although Natural is 
not a mutable type (and therefore this method 
should never be called by clients), it can be 
quite useful to mutate individual digits while 
you are constructing a new instance. 


digits: aSequence Take a sequence of x; and use it to initialize 
digits and degree. 

doDigitIndices: aBlock For 7 from zero to degree, send value 7 to 
aBlock. 

trim Set degree on the receiver as small as 


possible, and answer the receiver. 


degree Answer the degree of the receiver. 


makeEmpty: aDegree Set digits to an array suitable for 
representing natural numbers of the specified 
degree. (Also change the degree of the 
receiver to aDegree.) 


(b) Private instance methods for class Natural 


Figure 10.28: Suggested private methods for class Natural, array representation 


* The base method on the class provides a single point of truth about b, which 
you choose. 


* The digit-related methods are used to read, write, and iterate over digits. 


* Methods trim and degree are used to keep the arrays as small as possible, so 
leading zeroes don’t accumulate. 


* Method makeEmpty: is used to initialize newly allocated instances. 


The array representation offers these trade-offs: Because it provides easy ac- 
cess to any digit you like, it enables you to treat Smalltalk as if it were a procedural 
language, like C. In particular, you can get away without thinking too hard about 
dynamic dispatch, because a lot of decisions can be made by looking at digits and 
at degree. But the individual methods are a little complicated, and you may not 
learn a whole lot—my array-based code uses objects only to hide information from 
client code, and it doesn’t exploit dynamic dispatch or inheritance. 


Natural numbers: The subclass representation 


If a natural number is represented as a list of digits, I recommend defining two 
additional classes that inherit from Natural: NatZero and NatNonzero. An in- 
stance of class NatZero represents zero, and it doesn’t need any instance variables. 
An instance of class NatNonzero represents the natural number 7, +X’ - b, where 
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base Answers 0, the base of Natural numbers. 


first:rest: anInteger aNatural 
Answers a Natural number representing 
anInteger + aNatural - b. 


(a) Private class methods for class Natural 


modBase Answers a small integer whose value is the 


Saal receiver modulo b. 


object-orientation 


divBase Answers a Natural whose value is the receiver 
672 divided by b. 
timesBase Answers a Natural whose value is the receiver 
multiplied by b. 


compare:withLt:withEq:withGt: aNatural 1tBlock eqBlock gtBlock 
Compares self with aNatural. If self is 
smaller than aNatural, evaluate 1tBlock. 
If they are equal, evaluate eqBlock. If self is 
greater, evaluate gtBlock. 


plus:carry: aNatural c Answer the sum self + aNatural +c, where 
c is acarry bit (either 0 or 1). 


minus:borrow: aNatural c Compute the difference 
self — (aNatural +c), where c is a borrow bit 
(either 0 or 1). If the difference is nonnegative, 
answer the difference; otherwise, halt the 
program with a checked run-time error. 


(b) Private instance methods for class Natural 


Figure 10.29: Suggested private methods for class Natural, subclass representation 


Xo is a digit (a small integer), X’ is a natural number, and b is the base. Class 
NatNonzero needs instance variables for rg and X’; these might be called x-0 and 
other-digits. The representation invariants are that 7g and_X’ are not both zero, 
and0 < 29 < 0b. 

With the subclass representation, I recommend the private protocol in Fig- 
ure 10.29. 


* As with arrays, class method base provides a single point of truth about b. 


Class method first:rest: creates a new instance of one of the two sub- 
classes. If both arguments are zero, it answers an instance of class NatZero. 
Otherwise, it answers an instance of class NatNonzero. 


* Private methods modBase, divBase, and timesBase, together with public 
method isZero (Figure 10.22), are the protocol that allows a method to in- 
spect its argument. If a natural number X is x9 + X’ - b, then modBase an- 
swers 79 and divBase answers X’. (If a natural number is zero, it answers 
all of these messages with zero.) 


* The comparison method simplifies the implementations of methods < and =, 
which are subclass responsibilities of class Natural (from the Magnitude pro- 
tocol). 


* Methods plus:carry: and minus:borrow: implement functions adc and 
sbb, which are explained in Appendix B. 


The subclass representation offers these trade-offs: Because it provides easy ac- 
cess only to the least significant digit of a natural number (using modBase), it forces 
you to treat the other digits abstractly. The abstraction implies that many decisions 
about what to do next and when algorithms should terminate are made implicitly 
by dynamic dispatch: in each method, the action is determined by the class on 
which the method is defined. And each individual method is therefore simpler 
than corresponding methods that use the array representation; for example, the 
+ method defined on class NatZero simply answers its argument, and the * method 
simply answers zero. No conditionals, no scrutiny, end of story. But although the 
individual methods are simple, the overall algorithm makes sense only once you 
understand dynamic dispatch. 


10.9 TECHNIQUE IV: INVARIANTS IN OBJECT-ORIENTED PROGRAMMING 


Object-oriented programmers use the same program-design techniques that are 
described in Chapter 9 in the context of abstract data types—especially abstraction 
functions and invariants. In this section, an abstraction function and representa- 
tion invariant are used to implement a mutable linked list with an appealing cost 
model: linear-time traversal and constant-time access to first and last elements. 

As in Scheme, the representation uses cons cells. But unlike juScheme code, 
Smalltalk code never asks a list if it is empty or nonempty. Instead, empty and 
nonempty lists are represented by objects of different classes, and decisions are 
made by dispatching to the right method. 

To support efficient insertion and deletion at either end of a list, I represent 
it using a circular list of cons cells. This representation relies on a sophisticated 
invariant: both the beginning and end of the list are marked by a special cons cell, 
which is called a sentinel. A sentinel is a standard technique that often simplifies the 
implementation of a data structure (Sedgewick 1988). Andin Smalltalk, the sentinel 
can handle all the special cases normally associated with the end of a list, just by 
defining appropriate methods. As a result, the list code does not contain even one 
conditional that checks if a list is empty. 

Just as in wScheme, a cons cell holds two values: a car and a cdr. Unlike in 
pScheme, the cdr always points to another cons cell. This invariant holds because 
every list is circularly linked—the other cons cell might be a sentinel. For example, 
a list containing the elements 1, 2, and 3 (plus a sentinel) is structured as follows: 


The sentinel contains two pointers: the cdr (solid line), which it inherits from class 
Cons, points to the elements of the list, if any; the pred (dashed line), which is found 
only on objects of class ListSentinel, points to the sentinel’s predecessor. 

A sentinel’s predecessor is normally the last element of its list, but when a list 
is empty, both fields of its sentinel point to the sentinel itself: 


— 
) 


sentinel 


When the cdr points to the sentinel itself, the abstraction function maps the rep- 
resentation to the empty sequence. When the cdr points to another object, that 
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object is a cons cell, and the abstraction function maps the representation to the 
sequence of objects stored in the cons cells pointed to by the cdr of the sentinel. 
Each cons cell, including the sentinel, responds to the protocol shown in Fig- 
ure 10.30 (on the next page). 
A List object has only one instance variable: a pointer to the sentinel. 
674a. (collection classes 656c) += (S548d) <661a S563> 
(classes that define cons cells and sentinels 675b) 
(class List 
[subclass-of SequenceableCollection] 
[ivars sentinel] 


(class-method new () (C(super new) sentinel: (ListSentinel new))) 
(method sentinel: (s) (set sentinel s) self) ; private 

(method isEmpty 6) (sentinel == (sentinel cdr))) 

(method last Cy (Csentinel pred) car)) 

(method do: (aBlock) ((sentinel cdr) do: aBlock)) 


(other methods of class List 674b) 
) 


The method addLast: mutates a list by adding an element to the end. This 
means inserting an element just after the predecessor of the sentinel. Similarly, 
addFirst: inserts an element just after the sentinel. Having a sentinel means there 
is no special-case code for an empty list. 


674b. (other methods of class List 674b)= (674a) 674cD 
(method addLast: (item) ((sentinel pred) insertAfter: item) self) 
(method addFirst: (item) (sentinel insertAfter: item) self) 
(method add: (item) (self addLast: item)) 


Method removeFirst removes the element after the sentinel; removeLast is left 
as Exercise 25. 


674c. (other methods of class List 674b) += (674a) 1674b 674d> 
(method removeFirst () (sentinel deleteAfter)) 
(method removeLast () (self leftAsExercise)) 


Method remove: ifAbsent:, which removes an element holding a given object, 
uses the private cons-cell protocol described in Figure 10.30; the private method 
rejectOne:ifAbsent:withPred: is modeled on the more general reject: method 
defined on all collections. 
674d. (other methods of class List 674b) += (674a) 1674c 674e> 

(method remove:ifAbsent: (oldObject exnBlock) 
((sentinel cdr) 
rejectOne:ifAbsent:withPred: 
[block (x) (oldObject = (x car))] 
exnBlock 
sentinel) ) 


Method removeKey:ifAbsent: is left as an exercise. 


674e. (other methods of class List 674b) += (674a) 674d 674£> 
(method removeKey:ifAbsent: (n exnBlock) (self leftAsExercise) ) 


List is a subclass of SequenceableCollection, so it must answer messages in- 
volving integer keys. The first key in a List is always 0. 
674f. (other methods of class List 674b) += (674a) 674e 675a> 


(method firstKey () 0) 
(method lastKey () ((self size) - 1)) 


car 
cdr 
car: anObject 
cdr: anObject 


pred: aCons 


Answer the car of the receiver. 
Answer the cdr of the receiver. 
Set the receiver’s car and answer the receiver. 
Set the receiver’s cdr and answer the receiver. 


Notify the receiver that its predecessor is the cons 
cell aCons. 


deleteAfter 


insertAfter: anObject 


Delete the cons cell that the receiver’s cdr points 
to. Answer the car of that cons cell. 


Insert a new cons cell after the receiver, letting the 
new cons cell’s car point to anObject. Answer 
anObject. 


do: aBlock 


rejectOne:ifAbsent:withPred: aBlock exnBlock aCons 


For each cons cell c in the receiver, excluding the 
sentinel, use a value: message to send (c car) to 
aBlock. 


Starting at the receiver, search the list for a cons 
cell c such that (aBlock value: c) is true. If sucha 
cell is found, remove it. Otherwise, answer 
(exnBlock value). As a precondition, the 
argument aCons must be the predecessor of the 
receiver. 


(a) Instance protocol for all cons cells 


pred Answer the predecessor of the receiver. 


(b) Instance protocol for sentinels only 


Figure 10.30: Protocols for cons cells 


List element n is updated by skipping n cons cells and then sending the next cons 


call the car: message. 


675a. (other methods of class List 674b) += (674a) 4674f 
(method at:put: (n value) [locals tmp] 
(set tmp (sentinel cdr)) 
({(n isZero)? whileFalse: 


{(set n (n - 1)) 


(set tmp (tmp cdr))%) 


(tmp car: value) 
self) 


If n is out of range, the method can produce wrong answers—which can be made 


right (Exercise 26). 


The low-level work of manipulating pointers is done by the methods in the cons- 


cell protocol (Figure 10.30). 


675b. (classes that define cons cells and sentinels 675b) = (674a) 677> 


(class Cons 


[subclass-of Object] 


[ivars car cdr] 


(methods of class Cons 676a) 
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The first four methods of class Cons expose the representation as a pair of car 
and cdr. And the pred: method makes it possible to tell any cons cell what its pre- 
decessor is—information that is used only by the sentinel. (A sentinel is an instance 
of a subclass of Cons.) 


676a. (methods of class Cons 676a)= (675b) 676b> 
(method car () car) 
(method cdr () cdr) 


(method car: (anObject) (set car anObject) self) 
(method cdr: (anObject) (set cdr anObject) self) 
(method pred: (aCons) nil) 


Methods deleteAfter and insertAfter: implement the standard pointer ma- 
nipulations for a circularly linked list. Circularity comes into play when a node is 
deleted or inserted; sending pred: notifies the node’s successor of its new prede- 
cessor. 
676b. (methods of class Cons 676a) += (675b) <676a 676c> 

(method deleteAfter () [locals answer] 
(set answer (cdr car)) 
(set cdr (cdr cdr)) 
(cdr pred: self) 
answer) 
(method insertAfter: (anObject) 
(set cdr (((Cons new) cdr: cdr) car: anObject)) 
((cdr cdr) pred: cdr) 
anObject) 


The iteration and removal methods take full advantage of object-oriented pro- 
gramming. By defining do: differently on classes and ListSentinel, I create 
code that iterates over a list without ever using an explicit if or while—all it does 
is method dispatch. To make the computation a little clearer, I present some 
of the methods of class Cons right next to the corresponding methods of class 
ListSentinel. 

The do: method iterates over a list of cons cells by first doing the car, then 
continuing with a tail call to the do: method of the cdr. The iteration terminates in 
the sentinel, whose do: method does nothing. 
676c. (methods of class Cons 676a) += (675b) <676b 676e> 

(method do: (aBlock) ; defined on an ordinary cons cell 
(aBlock value: car) 
(cdr do: aBlock)) 


676d. (iterating methods of class ListSentinel 676d)= (677) 676f> 
(method do: (aBlock) nil) ; defined on a sentinel 


Similarly, method rejectOne:ifAbsent:withPred: checks the current cons 
cell to see if it should be removed, and if so, sends deleteAfter to its predeces- 
sor, which is passed as parameter pred. Otherwise, the method tries the next cons 
cell. If the method reaches the sentinel, it hasn’t found what it’s looking for, and it 
terminates the loop by sending the value message to the exception block. 
676e. (methods of class Cons 676a) += (675b) <676c 

(method rejectOne:ifAbsent:withPred: (aBlock exnBlock pred) 
((aBlock value: self) ifTrue:ifFalse: 
{(pred deleteAfter)? 
{(cdr rejectOne:ifAbsent:withPred: aBlock exnBlock self)3?)) 


676f. (iterating methods of class ListSentinel 676d) += (677) <676d 
(method rejectOne:ifAbsent:withPred: (aBlock exnBlock pred) 
CexnBlock value)) 


The final instance methods of class ListSentinel expose the pred pointer. And 
class method new allocates a new sentinel, whose pred and cdr both point to itself. 
Such a sentinel represents an empty list. 

677. (classes that define cons cells and sentinels 675b) += (674a) <675b 
(class ListSentinel 
[subclass-of Cons] 
[ivars pred] 
(method pred: (aCons) (set pred aCons)) 
(method pred () pred) 
(class-method new () 
[locals tmp] 
(set tmp (super new)) 
(tmp pred: tmp) 
(tmp cdr: tmp) 
tmp) 
(iterating methods of class ListSentinel 676d) ) 


10.10 OPERATIONAL SEMANTICS 


The operational semantics of :Smalltalk is in the same family as the operational 
semantics of jScheme: it’s a big-step semantics in which each variable name stands 
for a mutable location. And like jsScheme’s semantics, sSmalltalk’s semantics uses 
closures; a block in Smalltalk works about the same way as a lambda expression in 
pScheme. Butin several other ways, jsSmalltalk’s semantics works quite differently. 


* Unlike a block, a Smalltalk method does not evaluate to a closure; a method 
is represented as code plus a static superclass, with no other environment. 
When a message is dispatched to a method, the method's body is evaluated 
in an environment built from global variables, instance variables, message 
arguments, and local variables. Like arguments and local variables, the in- 
stance variables and global variables are not known until the message is sent. 
Because methods send messages that activate other methods, global vari- 
ables must be available separately, to help build the environment of the next 
method. The globals’ locations are therefore stored in their own environ- 
ment €. All other variables’ locations are stored in environment p. 


The semantics of return, which terminates the method in which it appears, 
cannot be expressed using the same judgment as the evaluation of an expres- 
sion. The return expression is a “control operator” like those described in 
Chapter 3, and like those other control operators, it could be described us- 
ing a small-step semantics with an explicit stack. But this would be a bad 
idea: unless you already understand how a language works, that kind of se- 
mantics is hard to follow. Instead, the return operator is described by a new 
big-step judgment form; with some parts omitted, the judgment looks like 
(e,---) t (vu, F;---), and it means that evaluating e causes stack frame F' to 
return value v. 


Every value is an object, and every object has both a class and a representation. 
When necessary, a value v is written in the form v = (class, rep). 


The behaviors of literal integers, symbols, and arrays are defined by classes, 
and if class SmallInteger, Symbol, or Array is redefined, the behaviors of 
the associated literals change. For example, if you complete Exercises 36, 38, 
and 39, you will change the behavior of integer literals to provide a seamless, 
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Table 10.31: Components of an initial state 


Metavariable What it stands for 

€ Expression Expression being evaluated 

p Environment Instance variables, arguments, and local variables 
Csuper Class Destination for messages to super 

P Stack frame Method activation that is terminated by return 

E Environment Global variables 

o Store Current values of all variables 

F Frame set Every activation of every method ever 


transparent blend of small- and large-integer arithmetic, all without touch- 
ing the uSmalltalk interpreter. The power comes at a price: if you make a 
mistake redefining SmallInteger, for example, you could render your inter- 
preter unusable. The dependence of behavior on the current definitions of 
classes like SmallInteger is reflected in the semantics. 


LSmalltalk’s semantics requires a more elaborate abstract-machine state than 
is needed for psScheme. jsScheme’s state, (e, p, 7), has only three components: the 
syntax being evaluated, the locations of all the variables, and the contents of all the 
locations. To specify message send, sending to super, and return, wSmalltalk’s 
abstract-machine state needs four more components (Table 10.31): 


* Environment € holds the locations of the global variables. It’s needed be- 
cause unlike a Scheme function, a method is given access to the global vari- 
ables defined at the time it receives a message, not at the time it is defined. 


* Class Csuper tracks the static superclass of the method definition within which 
an expression is evaluated. This class, which is not the same as the super- 
class of the object that received the message (Exercise 9), is the class at which 
method search begins when a message is sent to super. A static superclass 
is associated with every method and every block, and for all the expressions 
and blocks of a single method, it remains unchanged. 


* Stack frame fF tracks the method activation that return should cause to 
return. Like a static superclass, an active frame is associated with every 
method and every block, and for all the expressions and blocks of a single 
activation of a single method, it remains unchanged. 


* Set F records all the stack frames that have ever been used. It is used to 
ensure that every time a method is activated, the activation is uniquely iden- 
tified with a new stack frame F’. That device ensures in turn that if a return 
escapes its original activation, any attempt to evaluate that return results in 
a checked run-time error. The frame set F is threaded throughout the entire 
computation, in much the same way as the store o. 


Each individual component is used in a straightforward way, but the sheer num- 
ber can be intimidating. No wonder most theorists prefer to work with functional 
languages! 

The seven components listed in Table 10.31 form the initial state of an abstract 
machine for evaluating jsSmalltalk: (e, 0, Couper, F', €, 0, ). If expression e is eval- 
uated successfully, the machine transitions, expressing one of two behaviors: 


+ Ifan expression terminates normally and produces a value v, this behavior is 


represented by ajudgment of the form| (e, p, Couper, F,€,0, F) 1) (u30', F’) |. 


As usual for a language with imperative features, evaluating e can change 
the values of variables, so evaluation results in a new store o’. And evalu- 
ation may send messages and allocate new stack frames, so evaluation also 
produces a new used-frame set F’. But the main result of evaluation is the 
value v; o’ and F’ just capture effects. To make the judgment a little easier to 
read, v is separated from the effects using a semicolon, not a comma. 


+ If an expression evaluates a return, it immediately terminates an activa- 
tion of the method in which the return appears. I say it “returns v to 
frame F”’,’ and the behavior is represented by a judgment of the form 


(€, P; Couper, Ly €,0, F) t (v, F’; 0’, F’) |, with an arrow pointing up. Again, 


the main results are separated from the effects by a semicolon. 


If a syntactic form contains an expression, its evaluation can end in return behav- 
ior. But while we are learning the main part of the language, return behaviors are 
distracting. For that reason, the semantics of return are presented in their own 
section. 

Another complication of return is that its evaluation can terminate the eval- 
uation of a list of expressions. To express this behavior precisely, the semantics 
uses new judgment forms that describe the possible outcomes of evaluating a list 
of expressions. 


z ([etst25 erly; Cpl ea) a (Wiss @nlke ao) 


Evaluating a list of expressions produces a list of values [v1,..., Un]. 


* (leis: fear ls ps Guperm LOG OuF) t (Es er) 


Evaluating a list of expressions returns v to F’. 


The first judgment describes evaluation as it would happen in a language like 
pScheme, and its rules are worth giving right away. Formally, a list of expressions 
[e1,..-, €n] has one of two forms: it is [] or it has the form e :: es. The correspond- 
ing result of its evaluation also has two forms: it is |] or it has the form v :: vs. Each 
form has its own rule for evaluation. 


EMPTYLIST 
ThA. Comer E0F) 0 ho, F) 
(e, P, Csuper> FE, oO; F) a (u; CaF 
/ 7 sll W 
(es; Pp; Couper , €, 0 wee 1 (us; o iF ) (NONEMPTYLIST) 


(e 1 €8, P, Couper, Fy €, 0, F) A (v a us; 0", F") 


The rules for the second list-evaluation judgment are given with the rules for the 
other returns. 

Finally, because the value primitive evaluates a block, which can contain any 
pSmalltalk expression, the evaluation of a primitive requires its own form. A prim- 
itive gets access to global variables through €; it may change values of variables in 
the store 0; and it may allocate new stack frames, adding to F. When a primitive p 
is passed values v1, ..., Un, its behavior is therefore described using the judgment 


form (p, [u1,---,Un],§,0,F) dp (u; 0", F’) ig 
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10.10.1 Semantics of expressions without return 


The part of sSmalltalk’s semantics that is most compatible with jsScheme is the part 
that applies to situations in which no return is evaluated. Except for return, each 
syntactic form in Figure 10.9 (page 628) has a rule that describes its non-returning 
evaluation. (The semantics of return is deferred to Section 10.10.2.) 


Variables and assignment As in Impcore, environments p and € track local and 
global variables, but as in wScheme, they bind each defined name x to a muta- 
ble location. Aside from the extra bookkeeping imposed by messages to super and 
by returns, which manifests as extra components in the abstract-machine state, 
nothing here is new. 


xedomp p(r)=e 
(VAR(2), P, Csuper; F,€,0,F) 4) (o (0); 0, F) 
x«¢domp «xée€domgE E(a) = 
(vVAR(2), P, Csuper» P, SS oO, Fy (o(4); 0; F) 
Assignment to z translates x into a location @, then changes the value in @. Asin 


pScheme, the store is threaded. The set of allocated stack frames is threaded in the 
same way; evaluating expression e transitions that set from F to F’. 


TE dom p p(x) =f (e, p, Csuper> £, €, 0, F) al (uv; 0’, F’) 
(SET(2, €), p, Csuper, Py €, 0, Fe) a (uv; a'{e a v},F’) 


(VAR) 


(GLOBALVAR) 


(ASSIGN) 


x ¢ dom p x € dom € E(x) =£ (e, p, Couper) £,€,0,F) V (v30", F) 
(SET(X, €), P, Couper, F,€,0,F) | (uj a’ {0 4 v}, F’) 
(ASSIGNGLOBAL) 
Assignment to names self, super, true, false, and nil is not permitted, but this 
restriction is enforced in the parser, so it need not be mentioned here. 


Selfand super In sSmalltalk’s syntax, self is treated as an ordinary variable, but 
super is a distinct syntactic form. In most contexts, super is evaluated like self. 
(vAR(self), P; Csuper F, s oO, F) \ (0; 0; F) 
(SUPER, (, Csuper, L', €,0,F) |) (v3 0, F) 


(SUPER) 


When super identifies the recipient of a message, however, it behaves differently 
from self; to account for the difference in behavior, message send requires a spe- 
cial rule for messages sent to super (page 682). 


Values Asin Impcore, a VALUE form evaluates to itself without changing the store. 


Vv 
(VALUE(v), 2, Csuper, £ €, 0, F) 1 (v; 0; ie : pean 


Literals Aliteral evaluates to an instance of SmallInteger, Symbol, or Array. Only 
integer and symbol literals are formalized here. 


(LITERAL(NUM(7)), P; Csupers 26,0, F) 4) ((o(€(SmallInteger)), NUM(n)); 0, F) 
(LITERALNUMBER) 


(LITERAL(SYM(S)), P, Csuper, F',€,0,F) 4 ((o(€(Symbo1)), sym(s)); 0, F) 
(LITERALSYMBOL) 


The class of a literal number or a literal symbol is taken from the current global 
environment €, which means that a literal’s behavior can be changed by changing 
class SmallInteger or Symbol. 


Blocks A block is much like a lambda abstraction, except that its body es is a se- 
quence of expressions, not a single expression. Evaluating a block creates a clo- 
sure, which captures the current environment p, the static superclass Csuper, and 
the current stack frame I’. If the block is sent somewhere else and is evaluated in- 
side another method, as in the isEmpty method on class Collection (chunk 657e), 
for example, its return still terminates frame Ff’. 


v = (o(€(Block)), CLOSURE((%1,...,2n), €5, 2, Csuper, F')) 
(BLOCK((21, oes ,2h)s es), P; Csuper > F,g,0, F) al (v3 9, F) 


(MKCLOSURE) 


Sequential execution BEGIN expressions are evaluated as in wScheme: evaluate the 
expressions in sequence and produce the last value. 


E YBEGIN 
(BEGIN(), 2, Csupers £ €, 0; F) a (nil; oO; Fy hae ) 


(fer, - oe Cx Ps Caipanal SG Ose } ay ({v1,- — Unie ak.) 
(BEGIN(€1, €2,- . ees CLipers see, a (Un 3 OF) 


(BEGIN) 


Message send A message send takes place in four stages: evaluate the receiver 
and the arguments, find the method to dispatch to, set up a new environment and 
frame, and evaluate the method's body. The dispatch algorithm is expressed using 


the judgment form | m > c @ imp |, which should be pronounced “sending m to c 


is answered by imp.” The judgment means that sending a message m to an object 
of class c dispatches to the implementation imp. Judgment m> c@ imp is provable 
if and only if zmp is the first method named m defined either on class c or on one 
of c’s superclasses (Exercise 40). 

An ordinary message send tries m > c @ imp on the class of the receiver: 


e # SUPER 
(e, p, Superga L Our) 1 ({e,r); 0, Fo) 
(ler, os 1H ln sugary FS). O01 Fo) 1 ([u1, tect Vali Crs Pn) 


mb c@METHOD(_, (@1,..-,2n), (Y1,---;Yk),€m>$) 
F ¢ Fy 
l1,...,€n € domayn l4,...,0% ¢€doman 
ly,..-,4n,€1,...,@% all distinct 
p; = instanceVars((c,r)) 
Pa = {21 Gh,..-, an bn} 


p= {yr &,.--, Ye &} 
6 = On {fp Vig indy Unt Se Mh nl} 
(Cm Pi + Pa + pi, $F, £,6, Fn U{F}) Ue (uso, F’) 
(SEND(m, €, €1, -: -,€n); Ps Csuper, L', €, 7, F) 4 (Dio FD 


(SEND) 


The premise on the first line shows that this is a rule for an ordinary send, not a 
send to SUPER. The rest of the rule has much in common with the closure rule for 
Scheme: 


* The premises on the next two lines show the evaluation of the receiver e and 
of the arguments €1,...,€,. After these evaluations, we know we are send- 
ing message ™ to receiver r of class c with actual parameters 11,..., Un, and 
the store is On. 


* The premise m > c @ METHOD(_, (21,...,2n), (Y1,---5 Yk); Em; $) Shows 
that this send executes a method with formal parameters 71,...,2,, local 
variables y,,...,Yx, body e,,, and static superclass s. 
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The next three lines show the allocation of a fresh stack frame and of fresh lo- 
cations to hold the message arguments and the local variables of the method. 


* The equations for p;, Pa, and p; create environments for the receiver’s in- 
stance variables, the method's formal parameters, and the method’s local 
variables, respectively. 


* The equation for G initializes the formal parameters and the local variables. 


Finally, the last premise shows the evaluation of the body of the method e,,, 
in the new environment created by combining environments for instance 
variables, actual parameters, and local variables. Any returns go to the new 
stack frame F’. 


Function instanceVars is not specified formally. Calling instanceVars((c,r}), 
as defined in chunk 690a, takes the representation r of an object and returns an 
environment mapping the names of that object’s instance variables to the locations 
containing those instance variables. The environment also maps the name self to 
a location containing the object itself. 

When a message is sent to SUPER, the action is almost the same, except the 
method search takes place on Csuper, the static superclass of the current method, 
not on the class of the receiver. The new parts of the SUPER rule are shown in black; 
the parts that are shared with the ordinary SEND rule appear in gray. 


(SUPER, /), Csuper, F,€,0,F) 4) ((c, 7); 00, Fo) 
((e1,---5€n]; P, Couper, L, €, 00, Fo) | ([ui,..., Un]} Ons Fn) 
Mm © Csuper @ METHOD(_, (21,..-,: En) y (Y1y ++) Yk);€ms$) 

FEF 
bi,...,; é, ¢ domaoy, Es sats , € domaon, 
C1,.--5,€n,01,.--, 0% all distinct 
p; = instanceVars((c,1r)) 
Pa = {x1 b> Ly fa lovagee Ln, > Ly} 
pr={yit> t,-.-, Yn > Li} 
CZ Onli Uigenta etn Ey Mk, nt 
(Cm, Pi + Pa + 1,8, F',€,6,FU {F}) ) (vu; 0", F’) 
(SEND(™m, SUPER, €1,..., Cn); P; Csuper, L, €,0, F) | (u30', F’) 


(SENDSUPER) 


Primitives When a PRIMITIVE expression is evaluated, it evaluates its arguments, 
then passes them to the primitive named by p. 


(le1, ae eee Caper Gey) 1 ([u1, si Ge8 alee ak) 
(p, [u1,---,Un],€, 0", F’) Vp (uv; 0", F"") 
PRIMITIVE(D, €1,---5€n), P; Csu er, Oae 1 Uo se" 

p 


(PRIMITIVE) 


Each primitive p is described by its own rule. The most interesting one is the 
value primitive, which evaluates a block. Its rule resembles the rule for send- 
ing a message, except unlike a method, a block has no local variables or instance 
variables of its own. And the body of a block is evaluated using its stored return 


(Binssngen ley; ipa te yr) t OF So, F) 


(e, p, Gari ear) t OFS oF) 
(e 1 €S, Pp, Coupsiyl sep Oee } t re aa ae 


(e, P; Csuper BE, 0, F) a (v; ee ae §10.10 
(es, p, Cainer sts Gy 0, PF) t (v, I; Gk Operational 
(€:: €8, P; Couper, F,€,0,F) t (vu, F’30",F") semantics 
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(e, P; Csupers jae &; 0, oe) t (v, BY a’, F') 


(e, p, Csupers Py €, 0, ae a (uaF) 
(RETURN(€), p, Csupers FE, 0, oa t WF oF) 


(e, p, Csupers P €, 0; -) if QF eO.k) 
(SET(2, €), p, Csuper, £°, €, 0, F) 7 (Oo gd) 


(Eta: : -5€n]s Ps Cini evn) tT WaPo Fp 
(BEGIN(€1, Ss 5€n)> Ps Csupers ££, 0, F) t Gi yoo } 


(e, p, Caine Orr) t De citer ae 
(SEND(m, €, €1, oe i CalePs Couper, F €, 0, F) ab (yd ea Fy 


(e, p, Giyl eso. > 1 ((e,r); 00, Fo) 
(er, . Onl Os Caipany'y65 C0; Fo) t (230 5 F) 
(SEND(m, €, €1, pa yee Geipets les 055) t Oko oF) 


Figure 10.32: Rules for propagation of returns (other RETURN rules appear in the 
text) 


frame F, not the frame of the calling context. 


l1,.-.,4n domo = &4,..., &, all distinct 
6 =of{ly  4,...Ln Un} 
(BEGIN(e€S), Pe + {@1 +> €1,...,2n ln}, Se, Fe, €,6,F) |) (ujo', F’) 
(value, Ide, CLOSURE((21, ste ies €8,Se; Pes F.)),%1, ase Malone Fi Vp 
(v; 0’, F’) 
(VALUEPRIMITIVE) 


10.10.2 Semantics of returns 


Most of the rules for return describe variations on one situation: during the eval- 
uation of an expression e, one of e’s subexpressions returns, and this behavior 
causes ¢ also to return (Figure 10.32). But eventually the return terminates an acti- 
vation frame of the method in which it appears. When a return to frame F reaches 
a method body executing in frame F, the result of the return becomes the result of 
the SEND that activated the method. As with messages to super, the gray parts of 


the rule are the same as in SEND, and the black parts are different. 


(€, P, Couper, F, €,0, F) | ((c, r); 00, Fo) 
([e1,--+5€n]; Os Csupers 2, €, 00; Fo) 4 ([v1,---;Un]3 Ons Fn) 


m & c@ METHOD(_, (11,.--,2%n), (Y1,-++5 Yk); ms $) 
FEF 
ly,..., é, ¢ dom op, O1,...,0% ¢ dom an 
Smalltalk and C1,...,ln,01,..., 0% all distinct 
object-orientation p; = instanceVars((c,7)) 
684 aa a ya tracy tn bn} 
p= {yr & Mb os Yk + £L} 


6 =0n{fi PB O15: .0bln Un, fh nil, Be nil} 
(Em; Pi + Pa + pi.s,F,£,6,FU {F}) + (vu, Fs0', F’) 
(SEND(m, €, €1,---€n); Ps Couper, £', €,0, F) |) (u3o", F’) 


(RETURNTO) 


If method body e,,, tries to return somewhere else, to F'’, the whole SEND op- 
eration returns to F’. 


(€, P; Couper, F,€,0, F) Ib ((e, 7); 00, Fo) 
([e1,---5€n]; P) Couper, ££, 00, Fo) | ([ui,---, Un]; On; Fn) 
m & c@ METHOD(_, (@1,.--,Xn),(Y1,-++5Yk);€m;$) 
PEF 
Laisies asin é, ¢ domay O1,...,% ¢ dom an 
£y,..-,¢n,€1,..., 0% all distinct 
p; = instanceVars((c,7r)) 
Pa = {41 &,...,! Ln > Ly} 
p= {tyr &,---, Yr > Et 
G =On{li 0 U1,..-n A Un, OH nil,...& 9 nil} 
(ems Pi + Pa + ps 8, F, €,6,F U{F}) t (vu, F'; 0’, F’) F'AF 
(SEND(M, €, €1,---;€n); Ps Couper; F', €,0,F) t (vu, F"; 0’, F’) 
(RETURNPAST) 


10.10.3 Semantics of definitions 


A definition d is evaluated in the context of the top-level, persistent state of a 
pSmalltalk machine, which has only three of the seven components listed in Ta- 
ble 10.31: a global environment €, a store o, and a set of used stack frames F. Eval- 
uating d may change all three; the judgment form is (d, £,0, F) > (&',0', F’). 


Global variables As in jsScheme, a VAL binding for an existing variable x assigns 
the value of a right-hand side e to x’s location. Expression e is evaluated using 
the judgment form (e, P, Couper, F', €,0, F) | (vu; 0’, F’), so the VAL rule has to gin 
up an environment p, a class Csuper that will receive messages sent to super, and 
a new stack frame F’. Since e is evaluated outside any method, there are no in- 
stance variables and no formal parameters, and p is empty. To receive messages 
sent to super, the VAL rule uses the root class Object—the original definition of 
Object taken from the initial global environment €9, not whatever definition of 
Object happens to be current. (In practice, the identity of Csuper is irrelevant. If a 
message is sent to super, the abstract machine tries to look up self in the empty 


environment, and it gets stuck.) The new frame F is F , which may be any frame 
not previously allocated, that is, any frame not in F. 


wé€domé €(4)=f FEF 


(c, {}, €o(Object), F*, €,0, {F}UF) Ut vio’, F’) 
(vAL(a,e),€,0,F) > (E,0' {04 v}, F’) 


(DEFINEOLDGLOBAL) 
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(DEFINENEWGLOBAL) 


Top-level expressions A top-level expression is syntactic sugar for a binding to it. 
(vaL(it, €),€,0,F) > (,0',F') 
(ExP(e),€,0,F) — (6',0", F’) 


Block definition DEFINE is syntactic sugar for creating a block. 


(EVALEXP) 


(vAL(f, BLOCK((r1,.-.,2%n),€)),€,0,F) > (€',0', F') 
(DEFINE(f, (@1,.-.-,2n),e),§,0,F) > (€',0', F’) 


(DEFINEBLOCK) 


Class definition The evaluation of a class definition is rather involved; the inter- 
preter creates an object that represents the class. The details are hidden in the 
function newClassObject, which I don’t specify formally. To see how it works, con- 
sult the code in chunk 695a. 


xé€domgé €(a)=2 
v = newClassObject(d, €,c) 
(cLassD(d),£€,0,F) — (€,0{£+4 v},F) 


(DEFINEOLDCLASS) 


x¢domgé ¢¢doma 
v = newClassObject(d, €,c) 
(cLassD(d), £,0,F) > (E{a > bh afl v},F) 


(DEFINENEWCLASS) 


10.11 THE INTERPRETER 


The key parts of 4Smalltalk’s interpreter involve the elements that make Smalltalk 

unique: objects and classes. An object is represented in two parts: a class and an 

internal representation (ML types class and rep). The class determines the object's 

response to messages, and the internal representation holds the object’s state. And type class 686c 
although the Smalltalk word is “object,” the ML type of its representation is called type rep 686 
value, just like whatever thing an expression evaluates to in every other interpreter 

in this book. 

685. (definitions of value and method for Smalltalk 685) = (S548a) 686d > 

withtype value = class * rep 


The rep part of an object exposes one of the biggest differences between 
Smalltalk and Smalltalk-80. In Smalltalk-80, every object owns a collection of 
mutable locations, called “instance variables,” each of which can be filled either 
with an ordinary object or with a sequence of bytes. But because pSmalltalk is 
implemented in ML, raw locations and sequences of bytes are not useful represen- 
tations. In ~Smalltalk, every object owns a single representation, which is defined 
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by ML datatype rep. That representation may be a collection of named, mutable 
locations representing instance variables, or it may be any of half a dozen other 
primitive representations. 


686a. (definitions of exp, rep, and class for j1Smalltalk 686a)= (S548a) 686c > 
datatype rep 
USER of value ref env (* ordinary object *) 
ARRAY of value Array.array 
NUM of int 


CLOSURE of name list * exp list * value ref env * class * frame 
CLASSREP of class 


| 
| 
| SYM of name 
| 
| 
| METHODV of method (* compiled method *) 


A primitive representation is typically created by evaluating some particular syn- 
tactic form in the source code: an array literal, a numeric literal, a literal symbol, 
a block, a class definition, or a compiled-method form. Several representations 
(arrays, numbers, classes) can also be created by primitives. 

No matter what its internal representation, every object provides instance vari- 
ables to its methods. A USER object provides all the instance variables dictated by 
its class’s definition, a set that always includes self. An object with any other rep- 
resentation provides only self. 


686b. (utility functions on wSmalltalk classes, methods, and values 686b)= (S547) S587¢ > 


instanceVars : value -> value ref env 


fun instanceVars (_, USER rep) = rep 
| instanceVars self = bind ("Self", ref self, emptyEnv) 


Internally, an object’s class is represented by an ML value of type class. The in- 
ternal representation includes a superclass, instance-variable names, and meth- 
ods. A superclass is found on every class except the distinguished root class, 
Object. Aclass’s ivars and methods lists include only the instance variables and 
methods defined in that class, not those of its superclass. 


686c. (definitions of exp, rep, and class for j1Smalltalk 686a) += (S548a) <1686a 688a> 
and class 

= CLASS of ~ name : name (* name of the class *) 
, super : class option (* superclass, if any *) 
, ivars : string list (* instance variables *) 
, methods : method env ref (* both exported and private *) 
, class : metaclass ref (* class of the class object *) 
3 


and metaclass = PENDING | META of class 


Every class is also an object, and as an object, it is an instance of another class— 
its metaclass, which is stored in field class. This field initially holds PENDING, but 
when the metaclass becomes available, class is updated to hold it. 

Amethod has a name, formal parameters, local variables, anda body. A method 
also stores the superclass of the class in which it is defined, which it uses to interpret 
messages sent to super. 
686d. (definitions of value and method for jzSmalltalk 685) += (S548a) <1685 

and method = § name : name, formals : name list, locals : name list 
, body : exp, superclass : class 


3 


The class and value representations inform the representations of the ele- 
ments of the abstract-machine state (Table 10.31, page 678). 


- An expression e€ or definition d is represented in the usual way by a con- 
structed value from algebraic data type exp or def, as defined below. 


+ An environment por € is represented in the usual way by an ML environment 
of type value ref env. 


+ Asuperclass Csuper is represented by an ML value of type class. 


* A stack frame F is represented by an ML value of type frame. The defini- 
tion of frame isn’t important; it’s enough to know that a new frame can be 
allocated by calling newFrame, and that a frame is equal only to itself. 


* The store o and the set of used frames F are both represented by mutable 
state of the ML program. Just as in the other interpreters, 0 and o’ never 
coexist; instead, the interpreter updates its state, in effect replacing o by o’. 
The set F is updated to F’ in the same way. 


The value and frame types are also used to represent behaviors. 


* The behavior of producing a value, which is described by judgment form 
(e,...) d (u;0", F’), is represented by an ML computation that produces a 
value v of ML type value, while writing o’ and F’ over the previous o and F 
as a side effect. 


* The behavior of a Smalltalk return, which is described by judgment form 
(e,...) t (vu, F’; 0’, F’), is represented by an ML computation that raises the 
ML Return exception, again writing o’ and F’ as a side effect. The Return 
exception is defined as follows: 
687A. (definition of the Return exception 687a)= (S548c) 

exception 
Return of { value : value, to : frame, unwound : active_send list 3% 


Fields value and to hold vand fF’. And in the unhappy event that a block tries 
to return after its frame has died, field unwound is used to print diagnostics. 


Raising the Return exception, like any other exception, interrupts compu- 
tation in exactly the same way as the propagated returns described in Fig- 
ure 10.32 (page 683). That’s not a coincidence; both exceptions and returns 
are language features that are designed to interrupt planned computations. 


10.11.1 Abstract syntax 


Of the two major syntactic categories, expressions and definitions, it’s the defini- 
tion category whose forms most resemble forms found in other languages. A defi- 
nition may be one of our old friends VAL and EXP, a block definition (DEFINE), ora 
class definition (CLASSD). A class definition may include method definitions, which 
come in two flavors: instance methods and class methods. 
687b. (definition of def for Smalltalk 687b)= (S548a) 
datatype def = VAL of name * exp 
| EXP of exp 
| DEFINE of name * name list * exp 


| CLASSD of { name : string 
, super : string 
, ivars : string list 
, methods : method_def list 
3 
and method_flavor = IMETHOD (* instance method *) 
| CMETHOD (* class method *) 


withtype method_def = § flavor : method_flavor, name : name 
, formals : name list, locals : name list, body : exp 


3 
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type active_send 


bind 


emptyEnv 


type 
type 
type 
type 
type 


env 
exp 
frame 
name 
value 


$590c 
305d 
305a 
304 
688a 
$590a 
303 
685 
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The expression category also contains many forms that resemble forms found 
in other languages, but the forms that relate to literals are unique to ssSmalltalk. 
The forms defined by VAR, SET, SEND, BEGIN, and BLOCK have analogs in psScheme, 
LtML, and Molecule. (Even though blocks have two forms in concrete syntax, both 
with and without parameters, they have just one form in abstract syntax, with a 
list of parameters that might be empty.) Forms defined by RETURN, PRIMITIVE, and 
METHOD have no analogs in other interpreters, but they are also typical abstract syn- 
tax. And SUPER simply makes it easy to recognize super and give it the semantics it 
should have. But literal values are handled differently than in other interpreters. 

A literal must ultimately evaluate to an object, whose representation has type 
value. That representation includes a class, but until the interpreter is boot- 
strapped, most classes aren't yet defined (Section 10.11.6). For example, a literal 
integer can’t evaluate to an object until class Integer is defined. So a LITERAL ex- 
pression holds only a rep; its class isn’t computed until it is evaluated. 

The LITERAL form is complemented by a VALUE form. This form is used in- 
ternally, primarily as a way to turn an object into an expression that can receive 
a SEND. For example, the interpreter sends print1n to a VALUE form at the end of a 
read-eval-print loop, and it sends = to a VALUE form when testing a check-expect. 


688a. (definitions of exp, rep, and class for 4Smalltalk 686a) += (S548a) <1686c 
and exp = VAR of name 
SET of name * exp 
SEND of srcloc * exp * name * exp list 
BEGIN of exp list 
BLOCK of name list * exp list 


RETURN of exp 
PRIMITIVE of name * exp list 
METHOD of name list * name list * exp list 


SUPER 
LITERAL of rep 
VALUE of class * rep 


The abstract syntax for SEND includes a field that is not explicit in the concrete syn- 
tax: srcloc is the source-code location of the SEND, and it is used in diagnostic 
messages. 


10.11.2 Evaluating expressions, including dynamic dispatch 


Just as in the operational semantics, a psSmalltalk expression is evaluated in a con- 
text that tells it about environments p and € (rho and xi), a static superclass to 
which messages to super are sent, and the frame that is terminated if the expres- 
sion is return. The states o and o’ represent states of the underlying ML inter- 
preter, and the used-frame set F is stored in a mutable variable, so they are not 
passed explicitly. 

688b. (evaluation, basis, and processDef for psSmalltalk 688b)= (S548c) 691c> 


eval: exp * value ref env * class * frame * value ref env -> value 
ev : exp -> value 


fun eval (e, rho, superclass, F, xi) = 
let (definition of function invokeMethod 690a) 
(function ev, the evaluator proper 689a) 
in eve 
end 


Internal function ev handles all the syntactic forms, the most interesting of which 
are RETURN and SEND. 


Evaluating returns and sends A RETURN evaluates the expression to be returned, 
then returns to frame F by raising the Return exception. 


689a. (function ev, the evaluator proper 689a)= (688b) 689b> 
fun ev (RETURN e) = raise Return ~ value = ev e, to = F, unwound = [] 3 


That Return exception is caught by the code that interprets message send. 
The SEND code carries a lot of freight: it implements most of rules SEND, SEND- 
SUPER, RETURNTO, and RETURNPAST, and it also supports diagnostic tracing. The 


send and return rules all follow the same outline; for reference, that outline is for- §10.11 
malized by the first, highlighted part of the SEND rule: The interpreter 
e # SUPER 689 


(e, p, CSuperg Palys) a ({e,r); 00, Fo) 
(leis os eee supers Ps €, 0010) a ([v1, Pee sali Ons Pn) 


mb c@METHOD(_, (@1,..-,2n), (Y1,---;Yk),€m;§) 
F ¢F,, 
Cp ind os (,  domoy Blais og f', € dom ap, 
bites | ee ¢';, all distinct 
pi; = instanceVars((c,7)) 
Pa = {41> &1,...,: Ln, HY Ln} 
pr= {yi &,..., Yr > lt 


G = dn{hy > V41,.-. bn HF Un, A nil,... LH nil} 
(Cm; Pi + Pa + pis, F,£,6, Fr U { F}) ) (vu; 0", F’) 
(SEND(™m, €, €1, oe nj Ce) 0 Csupers £’, €, 0, F) 4 (Oo oF) 


(SEND) 


Each SEND computation begins in the same way: evaluate the receiver and the ar- 
guments using ev, then use the syntax of the receiver to identify the class on which 
method search begins. Message send dispatches on the receiver, whose class is 
used to find the method that defines message, except when the message is sent 
to super, in which case the superclass of the currently running method is used. 
At that point, because of tracing and returns, things start to get complicated, so let’s 
look at the code, then focus on the anonymous function passed to trace: 


689b. (function ev, the evaluator proper 689a) += (688b) <1689a 69laD 
| ev (SEND (srcloc, receiver, msgname, args)) = type class 686c 
let val obj as (class, rep) = ev receiver type env 304 
val vs = map ev args findMethod 690b 
val startingClass = type frame $590a 
case receiver of SUPER => superclass | _ => class Taare 
(definition of function trace $583b) nppeaten Sa 
in trace newFrame $590a 
(fn ( => type rep 686a 
let val imp = findMethod (msgname, startingClass) Return 687a 
val Fhat = newFrame () trace $583b 


in invokeMethod (imp, obj, vs, Fhat) type value 685 


handle Return ~§ value = v, to = F', unwound = unwound 3 => 
if F' = Fhat then 
v 
else 
(reraise Return, adding msgname, class, and loc to unwound $590d) 
end) 
end 


The anonymous function calls findMethod to get imp from m > c @ imp, and it 


allocates F’ as Fhat. It then delegates the second part of the SEND rules to function 
invokeMethod, except for the conditions in the RETURNTO and RETURNPAST rules. 


Those conditions are dealt with by handle, which catches every Return exception. 
If the Return is meant to terminate this very SEND—that is, if F’ = F'—then the 
anonymous function returns v as the result of the call to ev. If not, the anonymous 
function re-raises Return, adding information to the unwound list. 

What about function trace? It wraps the action of the anonymous function, 
so if findMethod results in a “message not understood” error, or if invokeMethod 
results in some other run-time error, trace can produce a stack trace. Function 
trace is defined in Appendix U. 


Smalltalk and h d fth easel abe Aedetion 
object-orientation The second part of the SEND rule is implemented by function invokeMethod. 
690 e # SUPER 
(€, P, Couper, F,&,0, F) 4) ((c, 7); 00, Fo) 
(le1,---; Cn], Ps Csupers fs €, 00; Fo0) Ve ([vi,---; Vil Ons Fn} 
m > c@ METHOD(_, (%1,...,: Ln), (Y1,-++5 Yk); ems 8) 
F ¢ Fy 


l1,...,4n € domon, C'4,...,0% €domon 
by,.--,bn €1,..., el all distinct 
pi = instanceVars((c,r)) 
Pa = {21 > €1,...,%n Ln} 
p= {yi Av ee SE} 
6 =on{l, 0 U1,...£n 9 Un, f 0 nil,... 8, nil} 
(Cm, Pi + Pa + pis, F,€,6, Fy U {F}) I) (u;.0', F’) 
(SEND(mM, €, €1,---,€n); P; Couper, Fy &,0,F) 1 (v30', F’) 


(SEND) 


Function invokeMethod computes f; as ivars, pq as args, and pf as locals. It also 


allocates and initializes locations /),...,, and ’,,..., ’%, then calls eval. 
690a. (definition of function invokeMethod 690a) = (688b) 
invokeMethod : method * value ¥* value list * frame -> value 


fun invokeMethod ({ name, superclass, formals, locals, body 3, 
receiver, vs, Fhat) = 


let val ivars = instanceVars receiver 

val args = mkEnv (formals, map ref vs) 

val locals = mkEnv (locals, map (fn _ => ref nilValue) locals) 
in eval (body, ivars <+> args <+> locals, superclass, Fhat, xi) 
end 


All that remains is findMethod. If m > c @ imp, then findMethod (m, c) re- 
turns imp. If there is no «mp such that m > c @ imp, then findMethod raises the 
RuntimeError exception. 


690b. (helper functions for evaluation 690b)= (S548c) 
findMethod : name * class -> method 
fun findMethod (name, class) = fm > class ~> method 


let fun fm (subclass as CLASS ~ methods, super, ...3) = 

find (name, !methods) 

handle NotFound m => 

case super 
of SOME c => fmc 
| NONE => 
raise RuntimeError (className class A 
"does not understand message " A m) 

in fm class 
end 


Allocating and evaluating blocks Evaluating a BLOCK form captures the current en- 
vironment, superclass, and stack frame in a closure. 
v = (o(€(Block)), CLOSURE((21,...,2n), €8, P, Csuper, £’)) 
(BLOCK((21,...,2n), €8), P, Csuper, ££, 0, F) | (v; 0, F) 


691a. (function ev, the evaluator proper 689a) += (688b) <1689b 691d> 
| ev (BLOCK (formals, body)) = mkBlock (formals, body, rho, superclass, F) 


(MKCLOSURE) 


Code inside a closure is evaluated by the value primitive. The value primitive is 

the only primitive that is mutually recursive with eval; it uses the function stored 

in applyClosureRef. 

691b. (ML code for remaining classes’ primitives 691b) = (S550c) 699b > 
type closure = name list * exp list * value ref env * class * frame 


val applyClosureRef : (closure * value list * value ref env -> value) ref 


= ref (fn _ => raise InternalError “applyClosureRef not set") 
fun valuePrim ((_, CLOSURE clo) :: vs, xi) = !applyClosureRef (clo, vs, xi) 
| valuePrim _ = raise RuntimeError "primitive ‘value‘ needs a closure" 


Once eval is defined, applyClosureRef can be initialized properly, to a func- 
tion that implements this rule: 


l1,...,4n domo = 44... , £, all distinct 
6=o{t; Hy U1,..-Ln > Un} 
(BEGIN(€S), Pc ab {1 Ee A, mt. » En > Cah Sey Paks 6, F a (v; o', F') 
(value, [(¢,CLOSURE( (i545 2%n)s€8; SeyPay Fo) Ps Vitesse ValiGsOe) Vp 
(v; 0’, F') 
(VALUEPRIMITIVE) 


(S548c) <1688b 693c> 
closure * value list * value ref env -> value 


691c. (evaluation, basis, and processDef for j1Smalltalk 688b) += 


applyClosure : 


fun applyClosure ((formals, body, rho_c, superclass, frame), vs, xi) = 
eval (BEGIN body, rho_c <+> mkEnv (formals, map ref vs), superclass, 
frame, xi) 
handle BindListLength => 
raise RuntimeError ("wrong number of arguments to block; expected " A 
"(<block> " A valueSelector formals A" "A 
spaceSep formals A ")") 
val () = applyClosureRef := applyClosure 


Evaluating literal and value forms A LITERAL form represents a literal integer or 
symbol, and it is evaluated by calling mk Integer or mkSymbol. These functions can- 
not be called safely until after the initial basis has been read and the interpreter has 
been bootstrapped (Section 10.11.6, page 697); for that reason, integer and symbol 
literals in the initial basis may appear only inside method definitions. 


(LITERAL(NUM(7)), P, Csupers £5 €,0,F) 4) ((o(€(SmallInteger)), NUM(n)); 0, F) 
(LITERALNUMBER) 


(LITERAL(SYM(S)), P, Csuper, F',€, 0, F) 4 ((o(€(Symbo1)), syM(s)); 0, F) 
(LITERALSYMBOL) 


691d. (function ev, the evaluator proper 689a) += (688b) <1691a 692aD 
| ev (LITERAL c) = 
(case c of NUM n => mkInteger n 
| SYM s => mkSymbol s 


| _ => raise InternalError "unexpected literal") 
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<+> 305f 
BEGIN 688a 

BindListLength 
305e 
BLOCK 688a 
CLASS 686c 


type class 686c 
className $588a 


CLOSURE 686a 
type env 304 
eval 688b 
type exp 688a 
find 305b 
type frame $590a 
instanceVars 

686b 
InternalError 

$219e 
LITERAL 688a 
mkBlock $561a 
mkEnv 305e 


mkInteger 698a 
mkSymbol 698a 
type name 303 

nilValue 696c 
NotFound 305b 


NUM 686a 

rho 688b 

RuntimeError 
$213b 


spaceSep S214e 
superclass 688b 


SYM 686a 
type value 685 
valueSelector 
S587c 
xi 688b 


By contrast, a VALUE form may be evaluated safely at any time; it evaluates to 
the value it carries. 


Vv 
(VALUE(V), 2, Csupers FY, &, 0; Fy 1 (v; 0, Fy : aes 


692a. (function ev, the evaluator proper 689a) += (688b) 691d 692b> 
| ev (VALUE v) =v 
Smalltalk and Reading and writing variables The VAR and SET forms are evaluated as we would 


object-ortentation expect; they use the local and global environments in the same way as Impcore. 


692 x €domp p(x) = £ es 
(VAR(Z), 0, Couper, £,€,0,F) |) (o(£)3 0, F) 
x«¢domp «xée€domE E(a)=2 
V. 
(VAR(2), P, Csupers F,€,0, F) 4 (a(0)30,F) (GLOBALVAR) 
a Label 
wedomp  pt)=f (6A, Couper 8,0) 4 (iat, F’) (ASSIGN) 


(SET(x, €), p, Csupers FE, 0, Fy 1 (uv; a'{e > Ot, Fo 


x ¢ dom p x € dom E(x) =£ (e, p, Ci Pree Ae Fr) 
(SET(X, €), P, Couper, F'€,0,F) 4 (us o/{£ > v}, F") 
(ASSIGNGLOBAL) 
692b. (function ev, the evaluator proper 689a) += (688b) <1692a 692c> 
| ev (VAR x) = !(find (x, rho) handle NotFound => find (x, xi)) 
| ev (SET (x, e)) = 
let val v=eve 
val cell = find (x, rho) handle NotFound _ => find (x, xi) 
in cell := v; v 


end 
The SUPER form is evaluated as if it were self. 


(VAR(self), 0, Couper, £', €,0, F) |) (v3.0, F) 
(SUPER, P; Csuper> PF, g, 0, F) 4) (vu; 0, F) 


(SUPER) 


692c. (function ev, the evaluator proper 689a) += (688b) <692b 692d> 
| ev (SUPER) = ev (VAR "Self") 


Sequential evaluation The BEGIN form is evaluated as in Impcore and pwScheme. 


E B 
(BEGIN(), ; Ccuper, F'€,0,F) dt (nil; 0, F) (EMPTYBEGIN) 


({e1, tee Cn] 2: Calpers ls CxO KE) a ({vr, oe sUnlkasF ) 
(BEGIN(€1, €2, tee €n)s Ps Cains Sey > a (Un; 0", F’) 


(BEGIN) 


692d. (function ev, the evaluator proper 689a) += (688b) <692c 693a> 
| ev (BEGIN es) = 
let fun b (e::es, lastval) = b (es, ev e) 
| b ¢ [], lastval) = lastval 
in b (es, nilValue) 
end 


Evaluating primitives Each wSmalltalk primitive is implemented by a function that 
expects a list of values and a global environment €. (The global environment is used 
only by the value primitive, which calls applyClosure.) The primitives are stored 


on the association list primitives list (Appendix U, page S550), and a PRIMITIVE 
form is evaluated by looking up the associated function on the list, then applying 
that function to the values of the arguments. 


693a. (function ev, the evaluator proper 689a) += 
| ev (PRIMITIVE (p, args)) = 
let val f = find (p, primitives) 
handle NotFound n => 
raise RuntimeError ("There is no primitive named " A n) 
in f (map ev args, xi) 
end 


(688b) 692d 693b> 


Compiled methods Acompiled-method is evaluated without actual compilation; its 
formal parameters, local variables, body, and current superclass go into an object. 
693b. (function ev, the evaluator proper 689a) += 
| ev (METHOD (xs, ys, eS)) = 
mkCompiledMethod § name = '", formals = xs, locals = ys 
, body = BEGIN es, superclass = objectClass 3 


(688b) <693a 


Function mkCompiledMethod is defined in the Supplement (page S570). 


10.11.3 Evaluating definitions 


Most definitions are evaluated more or less as in other interpreters, but class defi- 
nitions require a lot of special-purpose code for creating classes. 


Function evaldef, for evaluating definitions 


Evaluating a definition computes a new global environment, and it also has a side 
effect on the state of the interpreter. 


693c. (evaluation, basis, and processDef for uSmalltalk 688b) += (S548c) <1691c S548e> 


evaldef : def * value ref env -> value ref env * value 


ev : exp -> value 


fun evaldef (d, xi) = 
let fun ev e = eval (e, emptyEnv, objectClass, noFrame, xi) 
(handle unexpected Return in evaldef $590e) 
val (x, v) = 


case d 
of VAL (name, e) => (name, ev e) 
| EXP e => ("it", ev e) 


| DEFINE (name, args, body) => (name, ev (BLOCK (args, [body]))) 
| CLASSD (d as {name, ...%) => (name, newClassObject d xi) 
val xi' = optimizedBind (x, v, xi) 
in (xi', v) 
end 


This implementation is best understood in four steps: 


1. Define ev to evaluate an expression e in the context of a message sent to an 
instance of class Object: use an empty p, use Object as the superclass, and 
use the given xi. And because e is not in a method, there is no method in- 
vocation to which it can return, so its current frame F' is given as noFrame, 
which is different from any allocated frame. 


2. Analyze the definition d to find the name x being defined and to compute the 
value v that x stands for. Depending on the form of the definition, v may be 
the result of evaluating an expression, or it may be a new class object. 


3. Compute the new environment €’. 
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BEGIN 688a 
BLOCK 688a 
CLASSD 687b 
type def 687b 
DEFINE 687b 
emptyEnv 305a 
type env 304 


ev 689a 
eval 688b 
EXP 687b 
type exp 688a 
find 305b 
METHOD 688a 
mkCompiledMethod 
$570c 
newClassObject 
695a 
nilValue 696c 
noFrame $590b 


NotFound 305b 
objectClass 696a 
optimizedBind 
S587b 
PRIMITIVE 688a 
primitives S550d 


rho 688b 
RuntimeError 
$213b 
SET 688a 
SUPER 688a 
VAL 687b 
VALUE 688a 
type value 685 
VAR 688a 
xi 688b 
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mkClass : name -> metaclass -> class -> name list -> method list -> class 
methodDefns : class * class -> method_def list -> method list * method list 
setMeta : class * class -> unit 


className : class -> name 

classId : class -> metaclass ref 
methodName : method -> name 

methodsEnv : method list -> method env 


findClassAndMeta : name * value ref env -> class * class 


Figure 10.33: Utilities for manipulating classes (from the Supplement) 


4, Return é’ and v. 


Evaluating a VAL or EXP form evaluates the given expression and binds it to a name— 
either the given name or "it". DEFINE is syntactic sugar for a definition of a block. 
And evaluating a class definition binds a new class object, as described below. 


10.11.4 Class objects and metaclasses 


In both concrete and abstract syntax, a class definition can define methods in two 
flavors: instance method or class method. But in the operational semantics and 
at run time, there is only one flavor: “method.” What’s up with that? There truly 
is just one mechanism for dynamic dispatch, regardless of whether a message is 
sent to a class or to an instance. The distinction between instance method and 
class method is implemented by creating an extra, hidden class for each class in the 
system: a metaclass. Metaclasses aren't needed for writing typical Smalltalk code, 
but if you want to know how the system implements the two flavors of methods or 
how it creates new objects, metaclasses are essential. 
Metaclasses are governed by these invariants: 


+ Every object is an instance of some class. 
+ Every class is also an object—and is therefore an instance of some class. 
* Aclass whose instances are classes is called a metaclass. 


* Classes and metaclasses are one to one: every class has a unique metaclass, 
and every metaclass has a unique instance. 


* The instance methods of a class are stored in the class object. 
* The class methods of a class are stored in the metaclass object. 
+ Every metaclass is an instance of class Metaclass. 


* If a class C has a superclass, the metaclass of its superclass is the super- 
class of its metaclass. This invariant can be expressed as the algebraic law 
((C' superclass) metaclass) = ((C' metaclass) superclass). 


* Class Object has no superclass, and the superclass of its metaclass is class 
Class. 


The invariants dictate that classes and metaclasses be linked in memory in cir- 
cular ways: because every class points both to its superclass and to its metaclass, 
the graph of class and metaclass objects has a cycle. By itself, the “subclass-of” rela- 
tion has no cycles, but the “instance-of” relation has a cycle, and the combined re- 
lation has an additional cycle. The cycles are implemented by using mutable state: 
every class object is first created with a metaclass pointer that is PENDING; then its 
metaclass object is created; and finally the original class is mutated to point to the 
new metaclass. 


The representation of class objects is defined in code chunk 686c, but the large 
record type is awkward to manipulate directly. Instead, functions that manipulate 
ML values of type class do so using utility functions that are defined in Appendix U 
and are summarized in Figure 10.33 on the facing page. 

Atypical class object and its corresponding metaclass are both created by func- 
tion newClassObject, which is given the definition of the class. The new class has a 
superclass, which is found (along with its metaclass) by function findClass, which 
looks up the name of the superclass in environment €. The method definitions are 
segrated into class methods and instance methods by function methodDefns, which 
also attaches the correct static superclass to each method. The new class is built 
by mkClass, its metaclass is built by mkMeta, and the final class object is built by 
classObject. 
695a. (definition of newClassObject and supporting functions 695a)= (S548c) 

fun newClassObject $name, super, ivars, methods? xi = 
let val (super, superMeta) = findClassAndMeta (super, xi) 
handle NotFound s => 
raise RuntimeError ("Superclass " A s A" not found") 
val (cmethods, imethods) = methodDefns (superMeta, super) methods 
val class = mkClass name PENDING super ivars imethods 
val () = setMeta (class, mkMeta class cmethods) 
in classObject class 
end 


Function classObject uses CLASSREP to make the class a rep, then pairs it with 
the class of which it is an instance, that is, its metaclass. Any attempt to refer to an 
uninitialized metaclass results in a checked run-time error. 


695b. (metaclass utilities 695b) = ($550c) S588d> 


metaclass : class -> class 
classObject : class -> value 
fun metaclass (CLASS ~ class = ref meta, ... 3) = 


case meta of META c => c 
| PENDING => raise InternalError "pending class" 


fun classObject c = (metaclass c, CLASSREP c) 


When mkMeta creates a metaclass for class C, it gives C’s metaclass a superclass, 
that is, it finds the class that will be ((C metaclass) superclass). C’s metaclass’s 
superclass is actually found by function metaSuper, and as noted above, it is nor- 
mally ((C' superclass) metaclass). But when C has no superclass, its metaclass’s 
superclass is instead class Class. Internal representation classClass is defined 
below. 


695¢. (metaclasses for built-in classes 695c) = (S550c) 695d > 


metaSuper : class -> class 
fun metaSuper (CLASS ~ super = NONE, --. $) = classClass 
| metaSuper (CLASS £ super = SOME c_sup, ... 3%) = metaclass c_sup 


To make a metaclass for C’, function mkMeta needs C’s internal representation c 
and C’s class methods. The new metaclass is given a name derived from C’s name, 
and it is made an instance of class Metaclass. It has the superclass computed by 
metaSuper, no instance variables, and the given class methods. 


695d. (metaclasses for built-in classes 695c) += (S550c) 1695¢ 697c> 


class -> method list -> class 


fun mkMeta c classmethods = mkMeta : 


mkClass ("class " A className c) (META metaclassClass) (metaSuper c) 
[] classmethods 
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CLASS 686c 
type class 686c 
classClass 696d 
className $588a 
CLASSREP 686a 


findClassAndMeta 
$588c 
InternalError 
S2ige 
META 686c 
metaclassClass 
696d 


type method 686d 
methodDefns S589b 


mkClass S$588e 
NotFound 305b 
PENDING 686c 
RuntimeError 
$213b 
setMeta S588d 


10.11.5 The primitive classes 


Function newClassObject, in the previous section, is what’s called when a class 
definition is evaluated, and it is sufficient to create almost every class in jsSmalltalk. 
The exceptions are the four primitive classes, which are created using ML code: 


* Object is primitive because it has no superclass. 


* UndefinedObject is primitive because it is nil’s class, and nil is primitive 


Smalltalk and are : 
because a number of primitives need it, as does the evaluator. 


object-orientation 


* Class and Metaclass are primitive because they are needed to create new 
classes: every metaclass descends from class Class and is an instance of 
class Metaclass. 
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Every other class in the initial basis is defined by a class definition written in 
Smalltalk itself. 

Class Object is the ultimate superclass. To support the implementation of self, 
it has one instance variable, self. Defining self on class Object ensures that ev- 
ery user-defined object has an instance variable called self, into which, when a 
new object is created, function newUserObject places a pointer to the object itself 
(chunk 700). 
696a. (built-in class Object 696a)= ($550c) 

val objectMethods = 
internalMethods (methods of class Object, as strings (from chunk 634)) 
val objectClass = 
CLASS § name = "Object", super = NONE, ivars = ["self"] 
, Class = ref PENDING, methods = ref (methodsEnv objectMethods) 
3 


The (methods of class Object 634) are defined throughout this chapter and in Ap- 
pendix U, starting in chunk 634. 

Class UndefinedObject, whose sole instance is nil, redefines isNil, notNil, 
and print, as shown in chunks 654 and $559d. 
696b. (built-in class UndefinedObject and value nilValue 696b)= ($550c) 696c > 

val nilClass = 
mkClass "UndefinedObject" PENDING objectClass [] 
(internalMethods (methods of class UndefinedObject, as strings (from chunk 654) ) 


Class UndefinedObject has a single instance, internally called nilValue. To en- 
able it to be returned from some primitives, it is created here. 
696c. (built-in class UndefinedObject and value nilValue 696b) += ($550c) <696b 
val nilValue = 
let val nilCell = ref (nilClass, USER []) : value ref 
val nilValue = (nilClass, USER (bind ("self", nilCell, emptyEnv))) 
val _ = nilCell := nilValue 
in nilValue 
end 


Class Class is in the interpreter so that metaclasses can inherit from it, and 
Metaclass is here so that each metaclass can be an instance of it. 
696d. (built-in classes Class and Metaclass 696d)= ($550c) 
val classClass = 
mkClass "Class" PENDING objectClass [] 
(internalMethods (methods of class Class, as strings (from chunk 697a)) ) 


val metaclassClass = 
mkClass "Metaclass" PENDING classClass [] 
(internalMethods (methods of class Metaclass, as strings (from chunk 697b)) ) 


Most of the methods of class Class are relegated to Appendix U, but the default 
implementation of new is shown here: 


697a. (methods of class Class 697a)= S$559b > 
(method new () (primitive newUserObject self)) 

For metaclasses, this default is overridden; a metaclass may not be used to instan- 

tiate new objects. 

697b. (methods of class Metaclass 697b) = 


(method new () (self error: 'a-metaclass-may-have-only-one-instance) ) 


Internal classes classClass and metaclassClass are used in the implementation 
of mkMeta, shown above in chunk 695d. Once mkMeta is defined, it is used to create 
the metaclasses of classes Object, UndefinedObject, Class, and Metaclass. 


697c. (metaclasses for built-in classes 695c) += (S550c) <1695d 
fun patchMeta c = setMeta (c, mkMeta c []) 
val () = app patchMeta [objectClass, nilClass, classClass, metaclassClass] 


10.11.6 Bootstrapping for literal and Boolean values 


In most languages, literal integers, Booleans, and nil would be simple atomic val- 
ues. But in Smalltalk, they are objects, every object has a class, and relations among 
objects and classes include circular dependencies: 


When the evaluator sees an integer literal, it must create an integer value. 
That value must be an instance of class SmallInteger.!* 


Class SmallInteger is defined by Smalltalk code. 


Rw nN 


That code must be interpreted by the evaluator. 
Another circular dependency involves Boolean values and their classes: 


Value true must be an instance of class Boolean. 
Class Boolean must be a subclass of class Object. 


Class Object has method notNil. 


Rw NHN 


Method notNil must return true on class Object. 


Each of these things depends on all the others, creating a cycle that must be broken. 
Value false and method isNil participate in a similar cycle. 

Each cycle is broken with a well-placed ref cell. First, the ref cell is initialized 
with an unusable value; then the interpreter is bootstrapped by feeding it the defi- 
nitions of the predefined classes; and finally the ref cell is assigned its proper value, 
closing the cycle. The ref cells and the functions that update them are defined in 
the chunk (support for bootstrapping classes/values used during parsing 698a). The ref 
cells are used by primitives, by built-in objects, and by the parser. 


Cycles of literals When an integer literal is evaluated, the evaluator must create 
an object of class SmallInteger, which means that the evaluator requires a repre- 
sentation of SmallInteger. But that representation is created by evaluating a class 
definition (chunk $567b), which requires the evaluator! 

I break the cycle by reserving a mutable reference cell, intClass, to hold 
the representation of class SmallInteger. The cell is initially empty, but after 
the definition of SmallInteger is read, it is updated. The cell is used every time 
an integer literal is read: the evaluator calls function mkInteger, which fetches 
the SmallInteger class out of intClass. Provided SmallInteger has been read, 


12In full Smalltalk-80, an integer literal could also be an instance of a large-integer class. 
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intClass is not empty, and mkInteger creates and returns a new instance of the 
class. Otherwise, it crashes the interpreter by raising the InternalError excep- 
tion. Similar functions and reference cells are used to create objects from symbol 
literals and array literals. 

Because reference cells are hard to reason about, I define them inside ML’s 
local form. This form limits the scope of code that the reference cells can affect; 
the reference cells are accessible only to functions defined between local and end. 


Smalltalk and 698a. (support for bootstrapping classes/values used during parsing 698a) = (S547) 698b D> 
object-orientation mkInteger : int -> value 
mkSymbol : string -> value 
698 mkArray : value list -> value 
local 

val intClass = ref NONE : class option ref 

val symbolClass = ref NONE : class option ref 

val arrayClass = ref NONE : class option ref 


fun badlit what = 
raise InternalError 
C("(bootstrapping) -- can't " A what A " in predefined classes") 
in 
fun mkInteger n = (valOf (!intClass), NUM n) 
handle Option => badlit "evaluate integer literal or use array literal" 


fun mkSymbol s = (valOf (!symbolClass), SYM s) 
handle Option => badlit "evaluate symbol literal or use array literal" 


fun mkArray a = (valOf (!arrayClass), ARRAY (Array.fromList a)) 
handle Option => badlit "use array literal" 


Function val0f and exception Option are part of the initial basis of Standard ML. 

Once the predefined class definitions have been read, the reference cells are 
updated by function saveLiteralClasses, which takes one parameter, the global 
environment xi. 


698b. (support for bootstrapping classes/values used during parsing 698a) += (S547) <.698a 699a> 


findClass : string * value ref env -> class 


fun saveLiteralClasses xi = 


( intClass := SOME (findClass ("SmallInteger", xi)) 
; symbolClass := SOME (findClass ("Symbol", xi)) 
; arrayClass := SOME (findClass ("Array", xi)) 
) 


and findClass (name, xi) = 
case !(find (name, xi)) 
of (_, CLASSREP c) => c 
| _ => raise InternalError ("class " A name A " isn't defined") 
end 


Cycles of blocks The same drill that applies to literal expressions also applies to 
blocks: Evaluating a block expression creates an object of class Block, which also 
is not defined until its definition is read. Blocks are supported by these functions 
defined in Appendix U: 


mkBlock : name list * exp list * value ref env * class * frame -> value 
saveBlockClass : value ref env -> unit 


sameObject className addWithOverflow value 
class protocol subWithOverflow  printu 
isKindOf localProtocol mulWithOverflow printSymbol 
isMemberOf getMethod + newSymbol 
error setMethod = arrayNew 
subclassResponsibility removeMethod ¥ arraySize 
leftAsExercise methodNames div arrayAt 
newUserObject newSmallInteger < arrayUpdate 
superclass printSmallInteger > §10.11 
: waa The interpreter 
Figure 10.34: uSmalltalk’s primitives 
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Booleans Booleans also participate in a cycle, but it’s the Boolean objects, not the 
Boolean classes, that must be bootstrapped. Each Boolean object is stored in its 
own mutable reference cell. 
699a. (support for bootstrapping classes/values used during parsing 698a) += (S547) 4 698b S561a> 
local mkBoolean : bool -> value 
val trueValue = ref NONE : value option ref 
val falseValue = ref NONE : value option ref 
in 
fun mkBoolean b = valOf (!(if b then trueValue else falseValue) ) 
handle Option => raise InternalError “uninitialized Booleans" 
fun saveTrueAndFalse xi = 
( trueValue := SOME (!(find ("true", xi))) 
; falseValue := SOME (!(find ("false", xi))) 
) 
end 
10.11.7 Primitives 
pSmalltalk’s primitives are listed in Figure 10.34. Each primitive’s specification 
should be suggested by its name, but if you are uncertain about what a primitive 
does, you can study how it is used in predefined classes. 
A pSmalltalk primitive is almost the same thing as a zScheme primitive func- 
tion, and like a wScheme primitive function, it is represented as an ML function. 
ARRAY 686a 


For example, the value primitive is defined as function valuePrim in chunk 691b. 
Like psScheme’s primitive functions (Chapter 5, page 312), most of Smalltalk’s 
primitives are defined using higher-order ML functions in the interpreter. The def- 
initions are so similar to the examples in Chapter 5 that only a couple are worth 
showing here: class, which returns an object’s class, and newUserObject, which 
creates a new object. 

The class primitive takes an object as its single argument. The object is repre- 
sented by a pair that includes the object’s class, which is promoted to a full object 
by calling function classObject (chunk 695b). 


699b. (ML code for remaining classes’ primitives 691b) += (S550c) <1691b 700> 
val classPrimitive = unaryPrim (fn (c, rep) => classObject c) 


type class 686c 
classObject 695b 
CLASSREP 686a 


find 305b 
InternalError 
$219e 
NUM 686a 
SYM 686a 


unaryPrim $551la 
type value 685 
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The newUserObject primitive allocates fresh instance variables, each contain- 
ing nilValue. It then allocates the object, and finally it assigns self to point to the 
object itself. 


700. (ML code for remaining classes’ primitives 691b) += (S550c) <1699b S551b> 
mkIvars : class -> value ref env 
newUserObject : class -> value 

local 


fun mkIvars (CLASS § ivars, super, ... 3) = 
let val supervars = case super of NONE => emptyEnv | SOME c => mkIvars c 
in foldl (fn (x, rho) => bind (x, ref nilValue, rho)) supervars ivars 
end 
fun newUserObject c = 
let val ivars = mkIvars c 
val self = (c, USER ivars) 
in (find ("self", ivars) := self; self) 
end 
in 
val newPrimitive = classPrim (fn (meta, c) => newUserObject c) 
end 


10.12 SMALLTALK AS IT REALLY IS 


The Smalltalk language is so small and simple that jsSmalltalk can model almost 
all of it: assignment, message send, block creation, and nonlocal return. But 
Smalltalk-80 is not just a programming language. It is a programming system, uni- 
fying elements of programming language and operating system. And it is also 
an interactive programming environment. Neither of these aspects is captured 
in “Smalltalk, which is more of a Unix-style programming language: pSmalltalk 
programs are stored in a file system and are run by a standalone interpreter. 
Smalltalk-80, the programming system, is described in the first part of this sec- 
tion. Smalltalk-80, the programming environment, is not described here, because 
a book is not the right medium. (Two excellent Smalltalk environments, Squeak 
and Pharo, are readily available for download; I urge you to explore them.) Finally, 
in the rest of this section, Smalltalk-80’s language and classes are compared with 
pSmalltalk’s language and classes. 


10.12.1 Programming language as operating system 


Like all of the bridge languages, ;:Smalltalk fits comfortably into the development 
paradigm made popular by Unix: 


* Programs are stored in files, which are managed by an underlying operating 
system. 


* Whether a program is run by an interpreter or compiled by a compiler, it is 
invoked by an operating-system command, which finds the program in the 
file system. A program is typically invoked because a person typed some- 
thing at a shell. 


+ A program’s variables have to be initialized when the program is run, and 
when the program terminates, their values are lost. Persistent state is stored 
only in the file system. 


* Source code is edited and organized by programs that are unrelated to the 
interpreter or compiler, except they share a file system. 


* When code changes, programs that use the code are restarted from the be- 
ginning. 


Smalltalk-80 operates on a different paradigm: 


Programs are stored in an image of a running Smalltalk system. Operating- 
system abstractions like files are mostly irrelevant. 


Persistent state is stored in Smalltalk variables, not in files. The state of the 
entire Smalltalk image, including the values of the variables of all the objects 
and classes that are defined—that is, € and o—automatically persists. 


There are no programs or commands per se. Instead of “run a program,” the 
paradigm of execution is “send a message to an object.” Usually, the message 
is sent because a person interacted with a graphical user interface. 


Variables and objects don’t need to be initialized before code runs; they re- 
tain their (persistent) state from the time they were first created. And when 
code finishes running—that is, when a message send terminates—the inter- 
nal state of the relevant objects is (still) part of the image’s state, so it persists; 
nothing is lost. 


Source code is just data, and it need not live in files. It is stored in instance 
variables of objects, and it is edited by sending messages to objects—usually 
by means of the graphical user interface. 


Unless something goes dramatically wrong, images don’t terminate and 
aren't restarted. Sending a message to an object updates the image’s state 
in much the same way that running a Unix command updates the file sys- 
tem’s state. Restarting an image is a rare event, like restoring a file system 
from backup. 


This image-based paradigm has deep consequences for language design. Most 
dramatically, Smalltalk-80 doesn’t have definition forms! To create a new class, 
for example, you don’t evaluate a definition form; instead, you send a message 
like subclass: instanceVariableNames: to the superclass of the class you wish 
to create. It responds with a class object, to which you add methods by sending 
addSelector:withMethod: or something similar. Or more likely, you manipulate 
a graphical user interface which sends these messages on your behalf. 


10.12.2 Smalltalk-80’s language 
More literals and classes 


Smalltalk-80 provides all the forms of data that jSmalltalk does, and more besides. 
And more classes, including classes for characters and strings, can be instantiated 
by evaluating literal expressions: 


Class Literal 

Integer 230 

Character $a 

Float 3.39e-5 
Symbol #hashnotquote 
String ‘Spaces’ 


Array #($a Sb Sc) 


For symbols and arrays, Smalltalk-80 uses the hash mark, not our quote mark. 
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location: pointName 
tcenter + ((pointVectors at: pointName) * radius) 


locations: pointNames 
| locs | 
pointNames do: [:point | locs add: (self location: point)]. 
tlocs 


mutators 


adjustPoint: pointName to: location 
center < center + (location - (self location: pointName)) 


scale: k 
radius < radius * k 


drawing 


drawOn: picture 
self subclassResponsibility 


private 


center: c radius: r 
center < c. 
radius < r 


Figure 10.35: Class Shape, in Smalltalk-80 publication format 


Syntax in context, with postfix, infix, and mixfix message sends 


Smalltalk-80’s syntax is meant to be displayed using a graphical user interface. But 
I’m stuck with ink on paper. I could show screen shots, but because they don’t in- 
teract, they don’t do justice to the experience. Instead, just to give you a feel for con- 
crete syntax, I display code using the old “publication format” from the Smalltalk 


Blue Book (Goldberg and Robson 1983). 


As an example, the publication format of the Shape class (Section 10.1.5) is 
shown in Figure 10.35. This format isn’t source code; it’s a display—it is tuned to 
printed paper in much the same way that real Smalltalk is tuned to two-dimensional 
graphics. Compare this display of Shape with my code from page 621. The proto- 
cols and computations are the same, but both the abstract syntax and the concrete 


syntax are different. 


As noted above, full Smalltalk doesn’t use syntax for a class definition. 
The display at the top, which shows the class’s name, superclass, and in- 
stance variables, could be obtained by sending messages name, superclass, 
and instVarNames to the class object. 


Instead of tagging each individual method as a class method or an instance 
method, Smalltalk-80 displays groups of methods. These displays are also 
computed by sending messages to the class object. 


The Smalltalk-80 display shows information about subgroups of methods: “in- 
stance creation,’ “observing locations,’ “mutators,’ and “private.” These 
subgroups, which have no analog in Smalltalk, serve as documentation. 
In Smalltalk-80 the subgroups are called message categories. In more modern 
Smalltalks, a subgroup is called a protocol, just like the collection of messages 


as a whole. 


Each method definition is introduced by a line set in bold type; this line, 
which is called the message pattern, gives the name of the method and the 
names of its arguments. A method that expects no arguments has a name 
composed of letters and numbers. A method that expects one argument has 
a colon after the name; the name of the method is followed by the name of 
the argument. When a method expects more than one argument, the name 
of the method is split into keywords: each keyword ends with a colon and is 
followed by the name of one argument. This concrete syntax matches the 
concrete syntax of message sends, as shown below. 


When a method has two or more arguments, itis named by concatenating the 
keywords; thus, the private message is “center:radius:,” just as in Smalltalk. 


The display indents the bodies of the methods. The body of a method con- 
tains a sequence of statements, which are separated by periods. To return a 
value from a method, Smalltalk-80 uses return, which is written using the 
up arrow f or caret 4. A method that doesn’t evaluate a return answers self, 
but such a method is likely to be evaluated only for its effects, not its answer. 


The “<—” symbol is used for assignment. (Modern implementations use : =.) 


The most pervasive difference between Smalltalk-80 syntax and Smalltalk 
syntax is that when a keyword message is sent, the message’s arguments are 
interleaved with the parts of the message’s name. And parentheses are used 
only where they are needed to disambiguate. For example, in zSmalltalk we 
write, 


((Triangle new) adjustPoint:to: 'Southwest (s location: 'East)) 


but in Smalltalk-80, we write, 
Triangle new adjustPoint: #Southwest :to (s location: #East) 


As in Smalltalk, + and — are binary messages: a binary message is sent to 
a receiver and expects one argument. As with keyword messages, the send 
is written in receiver-message-argument form, for example, 3+ 4. Binary 
messages have higher precedence than keyword messages; for example, in 
the location: method, to prevent pointName from being interpreted as the 
receiver of *, the message send pointVectors at: pointName is wrapped in 
parentheses. 
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* Blocks are written in square brackets, notin curly braces. (uSmalltalk’s curly 
braces come from Ruby, aclose relative of Smalltalk.) And when a block takes 
arguments, its syntax is lighter weight than what wSmalltalk uses. Formal 
parameters are written after the opening “|” and before a vertical bar “|”; 
their names are preceded by colons. Thus, the ~Smalltalk block 


[block (x) (self add: x) ] 
is written in Smalltalk-80 as 
[:x | self add: x]. 


Smalltalk-80’s keyword syntax, which interleaves keywords and arguments, has 
rarely been emulated, although both Objective C and Grace use it. In several other 
languages, however, keyword syntax can be simulated, e.g., by passing a literal 
dictionary as an argument. 


More variables: Class instance variables and class variables 


In Smalltalk-80, a class object has its own instance variables, which are distinct 
from the instance variables of its instances. These variables are called class instance 
variables. Class instance variables are specific to a class, and their values are not 
shared with subclasses—they are, quite simply, the instance variables of the meta- 
class. Smalltalk-80 also has class variables, which, unlike instance variables or class 
instance variables, are shared: they are accessible to all the instances of a class and 
its subclasses, as well as the class itself and its subclasses. Class variables can make 
global variables unnecessary: because every class inherits from Object, the class 
variables of class Object can play the role of global variables. So in full Smalltalk, 
for example, the global point-vectors dictionary (page 622) would instead be a 
class variable of class Shape. 


Restricted primitives 


In Smalltalk, a primitive expression may appear anywhere within a method, 
with any arguments. In Smalltalk-80, primitives are numbered, not named, and 
a primitive may appear only at the beginning of a method, before any statements 
or expressions. 

With these restrictions, a Smalltalk-80 method may be defined as a numbered 
primitive followed by one or more expressions, possibly ending in a return: 


message-pattern 
<primitive n> 
expressions 


When the method is invoked, it executes the primitive numbered n. Ifthe primitive 
fails, the expressions are executed; if the primitive succeeds, its result is returned 
and the expressions are ignored. 

Primitives are not used by application programmers; as in Smalltalk, they are 
used only in methods of predefined classes. 


10.12.3  Smalltalk-80’s class hierarchy 


Smalltalk-80 comes with many, many class definitions. Only the Number and Col- 
lection subhierarchies are discussed here; these general-purpose classes are used 
by many programmers. Special-purpose hierarchies, including some that support 
graphics, compilation, and process scheduling, are beyond the scope of this book. 


Smalltalk-80’s numbers 


In Smalltalk-80, the part of the class hierarchy that contains numeric classes, which 
is the model for jzSmalltalk, looks like this: 


Object 


Magnitude 


ein 


Date Time Number 


Pay a 


Integer Float Fraction 
Smalllnteger LargePositivelnteger LargeNegativelnteger 


Classes Magnitude and Number resemble pSmalltalk’s versions, but Smalltalk-80’s 
Numbers respond to more messages than jSmalltalk’s Numbers. Classes Float and 
Fraction are likewise similar in both languages. And in Smalltalk-80, these classes 
are supported by more forms of literals: Smalltalk-80 provides floating-point liter- 
als, and its Integer literals may be arbitrarily long. (The class of an integer literal is 
determined by its magnitude and sign.) 

Like many languages, Smalltalk-80 supports mixed arithmetic; for example, 
Smalltalk-80 code can add a fraction to an integer, answering a fraction. But the 
class of the result is not determined by a static type system or even by the classes 
of the receiver and argument; instead, an arithmetic method conventionally an- 
swers an object of the least general class that can represent the result. Under this 
convention, the class of a result depends on the value of a receiver or an argu- 
ment, not just its class. For example, 10 raisedTo: 2 answers a Smalllnteger, but 
10 raisedTo: 20 answers a LargePositivelnteger. Smalllnteger is considered less 
general than LargePositivelnteger, which is considered less general than Float. 
That is why 10 raisedTo: 20 does not answer a Float. 

The implementations of the Number operations exploit the continue-after- 
failure semantics of Smalltalk-80’s primitives. For example, the definition of + 
on Smalllnteger uses primitive 1 to do the addition, but if the primitive fails, e.g., 
because the addition overflows, the succeeding statements automatically change 
over to large-integer arithmetic. The changeover is effected by the simple coercion 
asLargelnteger: 


+ aSmalllnteger 
<primitive 1> 
tself asLargelnteger + aSmalllnteger 


asLargelnteger 
self negative 
ifTrue: [tself asLargeNegativelnteger] 
ifFalse: [tself asLargePositivelnteger] 


Smalltalk-80’s Collection classes 


Smalltalk-80’s Collection hierarchy looks a bit different from the Collection hi- 
erarchy in wSmalltalk. The Smalltalk hierarchy is derived from the one in Tim 
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Budd’s (1987) Little Smalltalk. The Smalltalk-80 collection hierarchy looks, in part, 
like this: 


Object 
| 
Collection 


™ 
Set SequenceableCollection 
| = ™~ 
Dictionary LinkedList Arrayed Collection 
Array 


Both the Smalltalk-80 and the Smalltalk collection hierarchies use iteration (do:) 
as the fundamental operation. 


Collection protocols and the message cascade 


In wSmalltalk, when add: is sent to a collection, the collection answers itself. This 
protocol supports an idiom that is common in object-oriented languages, which is 
to modify a collection by sending it a sequence of messages. For example, 


(((C(List new) add: 1) add: 2) add: 3) // uSmalltalk 
List:new():add(1):add(2):add(3) -- Lua 
(new List).add(1).add(2) .add(3) // inspired by C++ 


This idiom applies to all sorts of mutable abstractions. But in Smalltalk-80, the add: 
message doesn’t work with this idiom: add: answers the object just added, not the 
collection receiving the message. What gives? 

It turns out that the idiom of sending a sequence of messages to a mutable 
abstraction is so useful that Smalltalk-80 provides special syntax for it: the mes- 
sage cascade. A receiver can be followed by a sequence of messages, separated by 
semicolons, and each message is sent in sequence to the same receiver. In Squeak 
Smalltalk, for example, the idiom works like this: 


OrderedCollection new add: 1; add: 2; add: 3; yourself 


This statement sends a cascade—a sequence of four messages—to the object an- 
swered by OrderedCollection new. The answer from the cascade is the answer 
from the last message. In this example, that’s yourself, which causes the receiver 
to answer itself: a list containing the elements 1, 2, and 3. 


Reflection 


In Smalltalk-80, aspects of a running image are themselves exposed as objects. 
These objects can be used by the image to manipulate itself; the ability of a pro- 
gram to manipulate itself is sometimes called reflection. Reflection makes it pos- 
sible to implement class browsers, compilers, debuggers, garbage collectors, and 
so on in the same language used to write applications. Smalltalk offers a taste of 
reflection in the form of methods like class and addSelector:withMethod:, buta 
full Smalltalk system offers much more. 

For example, given a class object, you can add or remove methods, query for 
particular methods, and call methods by name. You can compile or decompile code 
associated with methods. You can add or remove methods. You can change the 
superclass and add or remove subclasses. You can get the names of all the instance 
variables, which you can also add and remove. You can get information about the 
representations of instances. And so on. 


Even the “active contexts” (stack frames) used to implement message send are 
represented as objects. This means, for example, that a debugger or trace routine 
can visit all active contexts and display values of local variables and instance vari- 
ables, all using reflection. 


10.13 OBJECTS AND CLASSES AS THEY REALLY ARE 


While most popular object-oriented languages organize objects into classes, classes 
arent required. Object-oriented programming without classes is demonstrated 
most beautifully by the Self programming language. In Self, an object is a collection 
of named slots; a slot holds one object. Sending a slot name to an object answers 
the value of the object in the slot, or if the slot holds a special “method object,” it an- 
swers the result of running the method. An object is created by giving the names 
and contents of its slots. An object may also be created by cloning another object, 
called the prototype. Cloning is a shallow copying operation; it creates a new object 
whose slots hold the same objects as the original. Self’s model of object-orientation 
has been adopted by JavaScript, and it is also used in Lua. 

Among popular object-oriented languages that do use classes, many are hy- 
brids. A hybrid language often includes primitive types that act like abstract data 
types, not like objects; the classic example is the int type found in C++ and Java. 
And in a hybrid language, a class may act as a static type, not just as a factory for 
making objects. In such a hybrid, a class behaves more like one of Molecule’s ab- 
stract data types than like one of Smalltalk’s classes. For example, in Modula-3 and 
C++, the arguments to methods have static types, and a class method can see the 
representation of any argument of the class. But the method interoperates only 
with objects of the class (or its subclasses); Smalltalk’s flexible, behavioral subtyp- 
ing (“duck typing”) is lost. 

One popular language that offers both forms of data abstraction is Java. A Java 
interface corresponds nicely to a Smalltalk protocol. And as long as the types of 
methods are written entirely using interfaces, Java supports object-oriented pro- 
gramming much in the style of Smalltalk, with behavioral subtyping—different im- 
plementations of an interface interoperate with one another. But the moment the 
type of a method's argument is written using a Java class, that class acts as an ab- 
stract data type, not as a factory that builds objects which answer a given protocol. 
The method gains access to the representation of the argument, but it loses the 
ability to interoperate: it works only with instances of the specified class (or of one 
of its subclasses). 


10.14 SUMMARY 


Smalltalk helped object-oriented languages take over the world. Object-orientation 
seems very effective for certain types of problems, including simulation, graph- 
ics, and user interfaces. Although classes, subclasses, and objects were first intro- 
duced in Simula 67, the compelling case for these ideas was made by Smalltalk. 
Many of Smalltalk’s programming-environment ideas were adopted by Apple, and 
for years Apple’s devices were programmed primarily using the object-oriented lan- 
guage Objective C, a relative of Smalltalk. (Apple eventually replaced Objective C 
with Swift, which adds functional-programming ideas to the mix.) The wild ideas 
that Alan Kay thought might “amplify human reach” are now central to mainstream 
programming. 

An object is a bundle of operations that share state. When one of the operations 
is invoked, an implementation is chosen dynamically, and it can be different for dif- 
ferent executions of the same code. The bundle of operations and their behaviors 
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are specified by a protocol, which describes an abstraction. In a context expecting 
such an abstraction, any object that responds to the protocol may be used, regard- 
less of the class used to manufacture the object. This property of object-oriented 
programming is called behavioral subtyping or duck typing. 

In a pure object-oriented language, an operation has access only to the rep- 
resentation of the object on which it is defined; each argument is treated ab- 
stractly, through an interface or protocol. An operation that wishes to look at the 
representation of an argument must somehow extend the argument’s interface— 
perhaps simply by defining additional methods, like Smalltalk’s predefined nu- 
meric classes, or perhaps by using double dispatch, like the large-integer classes 
in the exercises. In a hybrid language like Java or C++, the abstraction presented by 
an argument may be compromised: a class may act not only as a factory that builds 
new objects but also as an abstract data type. This sort of hybrid gains the ability to 
inspect an argument’s representation directly, but it loses the ability to implement 
the argument’s abstraction with a representation that is independent of its original 
class. The distinction between class as object factory and class as abstract type is 
subtle, and in popular object-oriented languages, it can be hard to untangle. 


10.14.1 Key words and phrases 


ABSTRACT CLASS A CLASS used only to define METHODS, not to create INSTANCES. 
Other classes INHERIT from it. 


ABSTRACTION FUNCTION A function, used conceptually but not necessarily writ- 
ten in code, that maps the values of an object’s INSTANCE VARIABLES to the 
abstract thing the object represents. 


ANSWER Smalltalk’s term for the response to a message. Corresponds to a “return 
value” in other languages. Smalltalkers sometimes refer to an action “to an- 
swer,” which is analogous to the action “to return” found in other languages. 


AUTOGNOSTIC PRINCIPLE Cook’s (2009) term for a defining principle of object- 
oriented languages: an OBJECT has access only to its own REPRESENTATION, 
and it can access other objects only through their public interfaces or PRO- 
TOCOLS. 


BEHAVIORAL SUBTYPING A principle that says that if an object answers the same 
PROTOCOL as another object, and if it behaves in the same way, it may be 
considered to have the same type as the other object. Called DUCK TYPING by 
Ruby programmers, because “if it walks like a duck...” 


BLOCK An OBJECT much like a lambda abstraction, which is activated by sending 
it a MESSAGE. It has no instance variables. A block is a first-class value—an 
object with the same privileges as any other object. Smalltalk blocks are used 
as continuations to implement conditionals, loops, and exceptions. 


CLASS A specification for making OBJECTS. In Smalltalk, a class is also itself an 
object. 


CLASS METHOD A method that responds to messages sent to a class, rather than to 
instances of that class. Used most often to create or initialize instances of the 
class, as with the message new. 


COLLECTION One of several Smalltalk classes whose objects act as containers for 
other objects. Predefined collections include dictionaries, sets, lists, and ar- 
rays. A collection can be defined by just a handful of methods, of which the 


most important is the do: method, which iterates over the objects contained 
in the collection. The collection then inherits a large number of useful meth- 
ods from class Collection. 


COMPLEX METHOD A METHOD that wishes to inspect the representation of one or 
more ARGUMENTS, not just the RECEIVER. 


DATA ABSTRACTION The practice of characterizing a data type by its operations 
and their specifications, not by its REPRESENTATION. 


DELEGATION An implementation technique in which a METHOD is implemented 
by sending its MESSAGE to another object. For example, if a large integer 
is represented by a sign and a magnitude, the isZero method on large inte- 
gers might be implemented by sending the isZero message to the object that 
represents the large integer’s magnitude. 


EXPOSE THE REPRESENTATION Because Smalltalk methods are AUTOGNOSTIC, no 
method can ever inspect the representation of an argument—all a method 
can do with an argument is send messages to it. But an argument may de- 
fine methods that expose the representation. The most extreme example is to 
define a “getter” and “setter” method for every instance variable. This kind 
of exposure makes it easy to implement COMPLEX METHODS, but it destroys 
DATA ABSTRACTION. 


INHERITANCE The mechanism by which a CLASs definition is combined with the 
definition of its SUPERCLASS to specify how objects of the class are made. 
Class definitions may be combined by SINGLE INHERITANCE or MULTIPLE 
INHERITANCE. 


INSTANCE When object O is made from the specification given by class C’, O is 
called an instance of C’. 


INSTANCE VARIABLE Part of the state of a Smalltalk OBJECT. An object’s instance 
variables are accessible only to that object’s own METHODS. 


MAGNITUDE A quantity like a date, a time, or anumber, of which it can be said that 
one precedes another, but that might not support arithmetic. 


MESSAGE A combination of a message name, which is used to select a METHOD, 
and actual parameters. Sent to an OBJECT. The name is called a MESSAGE 
SELECTOR. 


MESSAGE NOT UNDERSTOOD The error that occurs when an object receives a MES- 
SAGE that is not in its PROTOCOL. 


MESSAGE PASSING Smalltalk’s central control structure. Message passing sends 
a MESSAGE to an OBJECT. The message includes actual parameters, which 
are also objects. The receiver of the message first selects, and then invokes, 
a METHOD, the result of which is ANSWERED in reply to the message. 


MESSAGE SELECTOR The name that, together with arguments, constitutes a MES- 
SAGE. 


METHOD Code that is executed in response to a MESSAGE. Sometimes called an 
INSTANCE METHOD. Like a function, a method takes formal parameters and 
returns a result. A method has access to the INSTANCE VARIABLES of its RE- 
CEIVER, but not to the instance variables of any of its arguments. An object’s 
methods are determined by its CLASS. 
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METHOD DISPATCH The algorithm used to determine what METHOD is evaluated 
in response to a MESSAGE. A form of DYNAMIC DISPATCH. In Smalltalk, 
method dispatch begins with the class of the RECEIVER, looking for a method 
with the same name as the message. If no such method is found, method 
dispatch continues with the receiver’s superclass, and so on all the way up 
to class Object. If method dispatch fails, it does so with a MESSAGE NOT UN- 
DERSTOOD error. 


MULTIPLE INHERITANCE Describes a language in which a CLASS may INHERIT 
from more than one SUPERCLASS. When different superclasses provide con- 
flicting definitions, e.g., of the same method, the conflict must be resolved 
somehow. Multiple inheritance has had passionate advocates, but the suc- 
cess of Java has weighted the scales in favor of SINGLE INHERITANCE, and 
much of the passion has died down. 


NUMBER In psSmalltalk, a machine integer, rational number, floating-point num- 
ber, or arbitrary-precision integer. Machine integers are primitive, and 
arbitrary-precision integers are left as an exercise. Rational numbers and 
floating-point numbers are predefined. 


OBJECT The unit of DATA ABSTRACTION in Smalltalk. An object encapsulates mu- 
table state represented as INSTANCE VARIABLES and code represented as 
METHODS. Only an object’s own methods have access to its instance vari- 
ables. 


OPEN RECURSION When a method sends a message to self, the message may dis- 
patch to a method defined by a SUBCLASS. If the message being sent has the 
same name as the method from which the message is sent, what looks like a 
“recursive call” may not be a recursive call. This ability of message passing 
to “intercept” or “override” the apparently recursive call is called open recur- 
sion. The phrase “open recursion” is also used to describe the more general 
phenomenon of a message dispatching to a subclass method, even when the 
message name and method name are different. 


When open recursion is used extensively, as in the implementation of arith- 
metic, for example, understanding the sequence of actions taken by an algo- 
rithm requires you to piece together many methods, which can be difficult. 


OVERRIDE When a class defines a method that is also defined in a SUPERCLASS, 
every instance of that class uses the new definition, not the superclass defi- 
nition. The superclass definition is said to be overridden. Overriding is some- 
times called REDEFINING the superclass method. 


PRIVATE METHOD A method that is to be invoked only by other methods of the 
same CLASS, or of its SUBCLASSES. It is part of the class’s private PROTOCOL. 


In Smalltalk, the private method is purely a programming convention, as it 
is also in Python. In object-oriented languages with static type systems, the 
type system usually provides a mechanism to make a method private. 


PROTOCOL The set of MESSAGES to which an OBJECT can respond, together with 
the rules that say what actual parameters are acceptable and how the object 
behaves in response. 


RECEIVER In MESSAGE PASSING, the OBJECT to which a message is sent. A message 
need not have any actual parameters, but it is always sent to a receiver. 


REFLECTION A feature of full Smalltalk whereby methods, usually defined on class 
Class or class Object, provide information about the implementations of 
classes or objects, or enable a Smalltalk program to alter itself. One simple 
example is the method subclass: instanceVariableNames:, which can be 
sent to any class object to create a new subclass of that class. Smalltalk-80 
has many other reflective methods: all instances of a class, all instance vari- 
ables of an object, and so on. jsSmalltalk provides a cheap, plastic imitation 
of reflection, limited to such methods as class, addSelector:withMethod:, 
compiledMethodAt:, and a few others. 


REPRESENTATION INVARIANT A property that holds among all the INSTANCE VARI- 
ABLES of an OBJECT, and which the object’s METHODS rely on. Representa- 
tion invariants must be established and maintained by an object’s own meth- 
ods and by the methods of its subclasses. 


self A keyword used within a METHOD to refer to the RECEIVER of a MESSAGE. 
When a message is sent to self, METHOD DISPATCH begins with the class of 
the receiver, not the class in which the method is defined. In some object- 
oriented languages, “self” is written “this.” 


SINGLE INHERITANCE Describes a language in which a CLASS INHERITS from ex- 
actly one SUPERCLASS. Contrasted with MULTIPLE INHERITANCE. Smalltalk 
uses single inheritance. 


SUBCLASS A class that INHERITS from a SUPERCLASS. A class may have many sub- 
classes or none. And a subclass of a subclass is also called a subclass. 


super A special keyword that bypasses the normal METHOD DISPATCH algorithm 
and dispatches directly to a method defined in the SUPERCLASS of the class 
in which super appears. 


SUPERCLASS A class named in a class definition, from which the defined class in- 
herits INSTANCE VARIABLES and METHODS. Except for the primitive class 
Object, every class has a unique superclass. Class Object has no superclass. 
To confuse matters slightly, a superclass of a superclass is sometimes also 
called a superclass. 


10.14.2 Further reading 


Smalltalk was invented to help create a computing experience that might deserve 
to be called “personal.” Smalltalk was part of a flood of inventions that emerged 
from the Xerox Palo Alto Research Center (PARC): the one-person computer; the 
bitmapped display; the user-interface elements that we now call windows, menus, 
and pointing; the use of abstract data types in systems programming; and many 
other delights that we have long since taken for granted. PARC’s Smalltalk group 
wanted to create a software system that would make the computer “an amplifier for 
the human reach,” not just a tool for building software systems. Alan Kay’s (1993) 
account of those heady days is well worth your time. 

Smalltalk-80 is described by the “blue book,” by Goldberg and Robson (1983), 
which is so called because of its predominantly blue cover. The blue book intro- 
duces the language and class hierarchy. It also presents five chapters on simula- 
tion and five chapters on the implementation and the virtual machine on which it 
is based. The blue book strongly influenced the design of sSmalltalk, especially its 
blocks. The “red book” (Goldberg 1983) describes the Smalltalk-80 programming 
environment and its implementation. A “green book” describes some of the early 
history of Smalltalk (Krasner 1983), and Ingalls (2020) describes the evolution of 
the language and its implementation from Smalltalk-72 onward. 
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Smalltalk was the subject of an August 1981 special issue of Byte magazine 
(Byte 1981). The issue includes twelve articles on the system, written by the peo- 
ple who built it. Topics range from design principles to engineering details, with 
plenty of examples, plus a description of the programming environment. A nar- 
row, deep introduction to the Smalltalk-80 language and programming environ- 
ment is presented by Kaehler and Patterson (1986), who develop a single, simple 
example—the towers of Hanoi—all the way up to an animated graphical version. 

If you want to use a Smalltalk system, Ingalls et al. (1997) describe Squeak, 
a free, portable implementation of Smalltalk that is written in Smalltalk itself. 
To get started, you will want help with the integrated programming environment, 
which is otherwise overwhelming; consult Black et al. (2009). Or you could try 
Pharo (Ducasse et al. 2016), a fork that looks better to modern eyes. 

If you want something simpler than Smalltalk-80 but more ambitious than 
Smalltalk, Budd (1987) describes “Little Smalltalk,” which is nearly identical to 
Smalltalk-80, but which lacks some extras, especially graphics. Budd’s book is eas- 
ier reading than the blue book, and interpreters for Little Smalltalk are available. 

No book tells you everything you need to know to become an effective Smalltalk 
programmer. You must master the class hierarchy, and to gain mastery, you must 
read and write code. As you write, be guided by Beck (1997), who discusses coding 
style; Beck’s excellent book will help you make your Smalltalk code idiomatic. 


Object-oriented programming predates Smalltalk; the first object-oriented lan- 
guage was Simula 67, which introduced objects, classes, and inheritance (Dahl and 
Hoare 1972; Birtwistle et al. 1973). As its name suggests, Simula 67 was designed 
with discrete-event simulation in mind. Simula 67 inspired the designers of CLU, 
Smalltalk, and C++, among others. 

Object-oriented languages without classes are rare. The first such language, 
and still one of the simplest and most innovative, is Self (Ungar and Smith 1987). 
Another such language, whose semantics is admittedly cluttered with strange be- 
haviors and corner cases, is JavaScript. (Part of the clutter is a class keyword, 
which JavaScript acquired in 2015. Think of class as defining a function that cre- 
ates an object with prototypes and slots.) Underneath the clutter is a language with 
good bones, which come from Scheme and from Self; for a view of the good parts, 
see Crockford (2008). And object-oriented programs can be written in a language 
without objects, provided the language has associative arrays and first-class func- 
tions. This idea and the corresponding programming techniques are described in 
a nice tutorial by Ierusalimschy (2016, chapter 21). 

Object-oriented programming has become so popular that many, many pro- 
gramming languages identify as object-oriented or include object-oriented fea- 
tures. C++ (Stroustrup 1997) adds object-oriented features—and many others 
besides—to C. Objective C also extends C with objects; its object-oriented features 
look much more like Smalltalk than like C++ (Cox 1986). Objective C was, for many 
years, the language most often used to write software for Apple products. Modula-3 
(Nelson 1991) extends Modula-2 with objects. Modula-3 inspired the development 
of the scripting language Python (van Rossum 1998) and the general-purpose ap- 
plication language Java (Gosling, Joy, and Steele 1997). Another scripting language, 
Ruby (Flanagan and Matsumoto 2008), is more directly inspired by Smalltalk. 

Many statically typed object-oriented languages, including C++, Modula-3, and 
Ada 95, mix object-oriented ideas with ideas from abstract data types. Such mix- 
tures can be hard to understand. For a clear, deep analysis of abstract data types, 
objects, the differences between them, and mixtures thereof, consult Cook (2009). 
Cook analyzes each set of ideas separately, then applies both to a couple of popular 
languages, including both Java and Smalltalk. And for a foundational view of these 
two kinds of abstraction, consult Reynolds (1978). 


To understand any language that claims to be both statically typed and object- 
oriented, you can precede Cook’s analysis with a simpler question: Is subtyping 
distinct from subclassing? If not, then the designer has traded some of the open- 
ness and expressivity of object-oriented programming for some other good, like a 
simple type system. But there are type systems that can handle open languages, 
even those as flexible as Smalltalk. For example, Graver and Johnson (1990) de- 
scribe a type system for Smalltalk in which subtyping and subclassing are carefully 
distinguished. This type system is the basis for an optimizing Smalltalk compiler 
(Johnson, Graver, and Zurawski 1988). 

Behavioral subtyping is described formally by Liskov and Wing (1994), who pro- 
pose that any definition of subtyping should meet this criterion: if type r’ is con- 
sidered a subtype of 7, then any property that is provable about objects of type 7 
must also be true of objects of type r’. Liskov and Wing provide two definitions of 
subtyping that meet the criterion. 

While inheritance helps build open, extensible systems, it can compromise 
modularity. Because a subclass can mutate all of a class’s representation and can 
send to any of its private methods, it must understand everything that is going onin 
the class, lest it violate the class's invariants. Stata (1996) presents the problem and 
proposes a new programming-language mechanism which expresses the interface 
between a class and its subclasses, restoring modular reasoning. 

Object-orientation continues to inspire the design of new languages. Eiffel, 
which is described in the excellent book by Meyer (1992), is designed to support 
a particular object-oriented design methodology (Meyer 1997). Grace (Black et al. 
2012) is designed especially for teaching novices. Swift is a successor to Objective C 
for programming Apple devices (Buttfield-Addison, Manning, and Nugent 2016). 
Of the languages above, only Objective C, Python, and Ruby share with Smalltalk 
the property of being dynamically typed; the others are statically typed, or, in the 
case of Grace, optionally typed. Smalltalk itself can be extended with type checking 
(Johnson, Graver, and Zurawski 1988). 

The object-oriented ideas popularized by Smalltalk were quickly adopted into 
Lisp. The Flavors system (Cannon 1979; Moon 1986) was developed for MIT’s Lisp 
Machine as a “non-hierarchical” approach to object-oriented programming: a “fla- 
vor” takes the place of a class, and a new flavor can be defined by combining several 
existing flavors. Flavors influenced CommonLoops, a substrate that can be used to 
absorb ideas from Flavors and from Smalltalk into Common Lisp (Bobrow et al. 
1986), and eventually the Common Lisp Object System, an object-oriented exten- 
sion of Lisp usually called CLOS (Bobrow et al. 1988). 


10.15 EXERCISES 


The exercises are arranged by the skill or knowledge they call on (Table 10.36 on 
the following page). More than in other chapters, the exercises call on knowledge 
of pSmalltalk’s large initial basis. Highlights include new numeric classes and an 
enhancement to the interpreter. 


* Exercises 37 to 39 are the most ambitious exercises in this chapter. You will 
implement a classic abstraction: full integers of unbounded magnitude. 
The project is divided into three stages: natural numbers, signed large in- 
tegers with arithmetic, and finally “mixed arithmetic,” which uses small ma- 
chine integers when possible and transparently switches over to large inte- 
gers when necessary. These exercises will boost your object-oriented pro- 
gramming skills, and you will understand, from the ground up, an imple- 
mentation of arithmetic that should be available in every civilized program- 
ming language. 
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Table 10.36: Synopsis of all the exercises, with most relevant sections 


Exercises Sections Notes 

1 10.1 Using shape classes. 

2to5 10.1 Defining new shapes and new canvases. 

6and7 10.1 Creating new classes from scratch (for random 
numbers, see also §10.4.6). 

Smalltalk and 8 and9 10.3.4 Messages to super: their use for initialization, and 
object-orientation hei semantics: 
714 10 10.4.1 Equality and object identity. 

lland12 10.4.2 Redefinition of existing methods using the protocol 
for all classes: print methods for pictures (§10.4.5); 
pictures with floating-point coordinates (§10.4.6). 

13 to15 10.4.2 New methods on existing classes: identify 
metaclasses (§10.11.4), condition on nil, hash. 

16 10.6 Conditionals as dynamic dispatch: the 
implementation of class False. 

17 to 31 10.4.5, 10.7 Modifying existing collections and defining new 
collections. 

32 and 33 10.4.6, 10.7.1, Make class Char a magnitude (§10.4.2); define new 

10.8.2 magnitudes. 

34 to 39 10.4.6, 10.8 Numbers and arithmetic: reasoning about overflow; 
arithmetic between different classes of numbers; 
arbitrary-precision arithmetic. 

40 and 41 10.10.1, Method dispatch: understanding its semantics; 

10.11.2 improving its implementation using a method cache. 

42 10.11.2 Object-oriented profiling: finding hot spots by 


measuring what objects receive what messages. 


* Smalltalk’s method dispatch might seem inefficient. But many call sites dis- 
patch to the same method over and over—a property that clever implemen- 
tations exploit. In Exercise 41, you implement a simple method cache and 
measure its effectiveness. The results will surprise you. 


10.15.1 Retrieval practice and other short questions 


A. Inthe expression (c location: 'East), what is the receiver? What is the mes- 
sage selector? What is the argument? 


B. Inthe expression (c location: 'East), what is the role of the colon after the 
word location? If the colon were missing, what would go wrong? 


C. Why does class CoordPair have two protocols (a “class” protocol and an “in- 
stance” protocol)? What can you do with the messages in the class protocol? 
What can you do with the messages in the instance protocol? 


D. Ina language like C++, new signifies a syntactic form. But in Smalltalk, new 
isn’t special. When the Smalltalk expression (List new) is evaluated, what 
happens? 


E. Inthe expression (c location: 'East),cis an object of class Circle, and class 
Circle doesn’t define a location: method. So when the expression is evalu- 
ated, what happens? How does it work? 


What objects can the message class be sent to? What objects can the message 
superclass be sent to? 


Once a class is defined, can you go back and add, change, or remove methods? 
How? 


. Message ifTrue: is sent to a Boolean, but message whileTrue: is sent to a 
block. Why the difference? 


In the drawPolygon: method implemented on class TikzCanvas, what does the 
expression in square brackets evaluate to? When the resulting object is sent to 
coord-list as an argument to the do: message, what happens? 


A pSmalltalk list is just one form of collection—there are others. All collections 
understand messages that are analogous to the Scheme list functions map, 
app, filter, exists?, and fold. What is the Smalltalk analog of each of these 
list functions? 


When message at:ifAbsent: is sent to a keyed collection, why is the second 
argument a block? 


In Smalltalk, every number is a magnitude, but not every magnitude is a num- 
ber. What’s an example of something can you do with a Number that you can't 
do with a Magnitude? What’s an example of an abstraction that is a magnitude 
but not a number? 


. How is the message isNil implemented without a conditional test? 


The Magnitude protocol offers six relational operators plus operations min: and 
max:. But no individual magnitude class has to implement all of them. What 
operations have to be implemented by subclasses of Magnitude, like Integer 
or Fraction? And how do things work with the other Magnitude operations, 
which aren't implemented by the subclass? 


Study how return is used in the implementations of methods isEmpty and 
includes: on class Collection. Each of these methods has a body, which con- 
tains one or more nested blocks, one of which contains a return. When the 
return is evaluated, what evaluation or evaluations are terminated? 


To iterate over a list in jzScheme, we have to ask the list how it was formed—is it 
empty or nonempty? Iteration in Smalltalk doesn’t have to ask such questions. 
How is list iteration accomplished instead? 


Method = on class Fraction needs to know the numerator and denominator of 
both the receiver and the argument. How does the method get the numerator 
and denominator of the receiver? How does it get the numerator and denomi- 
nator of the argument? 


In the semantic judgment (e, /, Csuper, , €,0, F) | (v; 0’, F’), components e, 
p, €, and o have their familiar roles. What is the role of the component Cguper? 


In the semantic judgment (e, (, Csuper, F,€,0, F) + (v, F"; 0’, F’), what are 
the roles of the two frames F' and F’? In particular, what happens if those 
two frames are identical? 


In the evaluation of an expression of the form SEND(m, €, €1,..., Cn), Suppose 
that the evaluation of e; returns v to frame F’. Are expressions €2 to €,, evalu- 
ated? What rules of the operational semantics determine the answer? 


A Smalltalk class is also an object, but in the interpreter, it is represented as an 
ML record. How does such an object know what its class is? What is the name 
for the class of such an object? 
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V. A pSmalltalk literal like 1983 evaluates to an object of class SmallInteger. But 
class SmallInteger is itself defined using Smalltalk code, and that code has to 
be read by the parser! How is this cyclical dependence resolved? Can anything 
go wrong? 


10.15.2 Using shape classes 


1. 


Draw pictures. By combining adjustPoint:to: with location:, you can cre- 
ate pictures without ever having to do vector arithmetic—all the arithmetic is 
encapsulated in the two methods. Using adjustPoint:to:, location:, and 
the other methods defined on shapes and pictures, write Smalltalk code to 
draw each of these pictures: 


(a) 8 
(b) 
(c) (co (The radii of the circles are in the ratio 9 to 6 to 4.) 


10.15.3 New shapes and canvases 


2. 


3. 


4, 


Implement a new shape. Using Square as a model, implement class Triangle. 


Reuse code by defining and inheriting from a Polygon class. The square and tri- 
angle are both polygons, and both can be drawn in the same way, only using 
different points. Define a new, abstract class Polygon, which is a subclass 
of Shape, and which includes a method points. When sent the points mes- 
sage, a polygon should answer a list of symbols that name the control points 
that should be drawn. 


(a) Implement Polygon. Method drawOn: should use method points, 
which should be a subclass responsibility. 


(b) Redefine Square and Triangle to be subclasses of Polygon. The new 
Square and Triangle classes should define only the points method— 
all other methods should be inherited from Polygon. 


(c) As asubclass of Polygon, implement the new shape Diamond. 


(d) As subclasses of Polygon, implement the new shapes TriangleRight, 
TriangleLeft, and TriangleDown, whose triangles point left, right, and 
down. 


A scalable canvas. The startDrawing method of class TikzCanvas estab- 
lishes the scale that one unit is rendered as “4pt,” which means four printer’s 
points, or in FTX, about + of an inch. Change class TikzCanvas so that 
the size of a unit is an instance variable of the class, and add a class method 
withUnit: that can specify the initial scale. Use a symbol, so that you can 
specify a scale using any of the units BTpxX understands, as in these exam- 
ples: 


(TikzCanvas withUnit: '12pt) 
(TikzCanvas withUnit: '1cm) 
(TikzCanvas withUnit: '0.5in) 


The class method new will need to be changed, but sending new to class 
TikzCanvas should continue to create a canvas with a scale of 4pt. 


5. Anew class of canvas. In this problem, you replace TikzCanvas with a different 
back end. 


(a) Learn enough PostScript commands to draw pictures containing poly- 
gons and ellipses. For a whole picture, you'll need PostScript com- 
mands %!PS, scale, setlinewidth, and showpage. For polygons, you'll 
need newpath, moveto, lineto, closepath, and stroke. You can draw 
circles using arc, closepath, and stroke; to draw an ellipse, save the 


context using gsave and grestore, then use scale to adjust the x and y $10.15 

radii and draw a circle. Exercises 
(b) To draw PostScript pictures, define a new class PSCanvas. It should 717 

implement the same protocol as TikzCanvas, and it should produce 

PostScript. 


10.15.4 Creating new classes from scratch 


6. An object as a source of random numbers. For random-number generation, de- 
fine class Rand. An object of class Rand should have an internal seed, which is 
an integer, and should respond to the following protocol: 


* Class method new: creates a new random-number generator with the 
given seed. 


* Instance method next answers the random number and updates the 
seed. 


To generate the next random number, use the algorithms from page 124. 
7. Strings. Define a class SymbolString which represents a string of symbols. 


(a) Define a 4 method that concatenates a string or a symbol to a string of 
symbols. Should class SymbolString be mutable or immutable? 


(b) Now extend Symbol so that 4 is defined on symbols as well. Should class 
Symbol be mutable or immutable? 


10.15.5 Messages to super 


8. Correct initialization of new pictures. Section 10.3.4 says that sending newtoa 
class should answer a newly allocated object whose state respects the private 
invariants of the class. One such invariant, of class Picture, is that instance 
variable shapes refers to a list of shapes. But the definition of Picture in 
Figure 10.4 simply inherits new from Object, and new returns an uninitialized 
Picture object. The definition in Figure 10.4 does not include new because in 
such an early example, I did not want to introduce the technique of sending 
messages to super. Define new on class Picture so it creates a picture with 
an empty list of shapes, by sending empty to self. Then change the empty 
class method to use super. 


9. Alternative semantics for super. Suppose super were implemented like this: 
when sending message m to super, send it to self, but start the method 
search in the superclass of self’s class. Compare this implementation with 
the way super is actually implemented, and explain how they are different. 
Find an example from this chapter in which the incorrect version does the 
wrong thing. 


You may find it expedient to implement the incorrect version. 
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10.15.6 Equality 


10. Object identity for keys in collections. The collection classes compare keys with 


equivalence (=). What if you really wanted object identity (==)? You don’t 
have to rewrite all the code. Instead, try the following: 
(a) Define a Wrapped class that has the following properties: 


((Wrapped new: anObject) value) == anObject 
((Wrapped new: x) = (Wrapped new: y)) == (x == y) 


(b) Define a new collection class that inherits from one of the existing 
classes, but which overrides methods to use wrapped keys. 


10.15.7 Method redefinition 


11. Pictures with non-integer coordinates. The print method in the CoordPair 


class sends the print message to instance variables x and y. Aslong as x and y 
are integers, this works fine, but if they are any other kind of numbers, the 
syntax that Smalltalk prints won't be recognized by the BTpX TikZ package. 
In this exercise you modify both the Float and the CoordPair classes to sup- 
port shapes and positions with non-integer values, using MTpX syntax. 


(a) Redefine the print method on the Float class so that it prints self as 
an integer part, followed by a decimal point, followed by two decimal 
digits, as follows: 


718. (exercise transcripts 718) = 720a> 
-> (69 asFloat) 
69.00 
-> ((-3 / 4) asFloat) 
-0.75 
-> ((314 asFloat) / (100 asFloat)) 
3.14 


To redefine print, send addSelector:withMethod: to class Float with 
two arguments: the literal symbol 'print and a compiled-method ex- 
pression with the new method definition. 


(b) Establish a new invariant for class CoordPair: that the values of in- 
stance variables x and y are always numbers of class Float. Modify 
only methods of class CoordPair, not methods of any other class. 


(c) Make sure the public methods of class CoordPair work with arguments 
of any numeric class, not just integers or Floats. 


12. More informative print method for pictures. The print method of class 


Picture would be more interesting if it showed the shapes inside the pic- 
ture, like so: 


-> pic 
Picture ( <Circle> <Square> <Triangle> ) 


Make it so. (You might wish to study the print method for class Collection.) 


10.15.8 New methods on existing classes 


The exercises in the next group explore changes, extensions, and additions to the 
predefined classes. To modify a predefined class, you have two choices: 


+ Edit the source code of the interpreter. 


* Send the class the addSelector:withMethod: message, giving it the method 


name (as a literal symbol) and a compiled method, as in Exercise 11. 


The exercises are as follows: 


13. 


14. 


15. 


Method isMeta for all classes. In a full Smalltalk system, every class answers 
the message isMeta, saying if it isa metaclass. Define as many isMeta meth- 
ods as you need to, then use reflection to update wSmalltalk’s predefined 
classes so that every class object responds appropriately to isMeta. 


Method ifNil: for all objects. In a full Smalltalk system, message ifNil: can 
be sent to any object. The message takes one argument, which is a block. 
The receiver answers itself, unless the receiver is nil, in which case it an- 
swers the result of sending value to the argument block. Define as many 
ifNil: methods as you need to, then use reflection to update j:Smalltalk’s 
predefined classes so that every object responds appropriately to ifNil:. 


Give every object a hash method. In ppSmalltalk’s predefined classes, only ob- 
jects of class Symbol respond to a hash message. Using reflection, update the 
predefined classes so that every object responds to the hash message with a 
small integer. Equal objects must hash to equal values. 


10.15.9 Conditional tests via dynamic dispatch 


16. 


Conditional operations on class False. Study the implementation of class True 
in Section 10.6. Write the corresponding definition of class False. 


10.15.10 Collections 


17. 


18. 


Pictures as collections. A Picture is, among other things, a collection of 
shapes. Perhaps it should understand the entire Collection protocol? 


(a) Redefine Picture to make it inherit from Collection. It could inherit 
directly from Collection or from any of Collection’s (transitive) sub- 
classes. 


(b) Which is the better design: Picture as defined in Section 10.1, or 
Picture as a specialized collection? Justify your answer. 


A class Interval of integer sequences. An object of class Interval represents a 
finite sequence of integers in arithmetic progression. The sequence takes 
the form [n,n + k,n +2-k,...,.n +m-k] forsomen > 0,k > 0, 
and m > 0. An interval is defined by n, m, and k; intervals are im- 
mutable. An interval is a collection and answers the same protocol as any 
other sequenceable collection, except that it lacks add:. Interval’s class pro- 
tocol should provide two initializing methods: from:to: and from: to:by:. 
Sending (from:to:by: Interval n (n +m-k) k) should result in an inter- 
val containing the sequence shown above; (from:to: Interval n (n + m)) 
should use k = 1. 


Define class Interval as a subclass of SequenceableCollection. 
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19. 


20. 


21. 


22. 


23. 


Using Interval for array indices. Use class Interval to implement methods 
associationsDo:, collect:, and select: on arrays, and to re-implement 
do:. 


Class method withA11: for arrays. Extend class Array with an additional class 
method withAll: aCollection, which makes an array out of the elements 
of another collection. To add a class method using reflection, you send 
addSelector:withMethod: to Array’s metaclass, which you get by evaluating 
(Array class). 


Methods select: and collect: for arrays. Add implementations of select: 
and collect: to class Array. 


Collection class Bag. Define the collection class Bag. An object of class Bag is 
a grocery bag; it’s an unordered collection of elements. Unlike a set, a bag 
may contain the same element multiple times, as in two cartons of milk; bags 
are sometimes called multisets. A bag has the same protocol as Set, and it 
also answers count: by telling how many copies of a given object it holds. 
For example: 
720a. (exercise transcripts 718) += 1718 720b> 

-> (val B (Bag new)) 

-> (B add: 'milk) 

-> (B add: 'milk) 

-> (B add: 'macaroni) 

-> (B includes: 'milk) 

<True> 

-> (B count: 'milk) 

2 


Iterating through a bag should visit every item: 

720b. (exercise transcripts 718) += 1720a 
-> (B do: [block (x) ('Bagged: print) (space print) (x printlin)]) 
Bagged: milk 
Bagged: milk 
Bagged: macaroni 
nil 


Choose Bag’s superclass so as to require as little new code as possible, but do 
not change any existing classes. 


Arrays that can change size. Fixed-size arrays are a nuisance. Using the de- 
sign in Section 9.6.2 as a model, create an ArrayList class that inherits 
from SequenceableCollection and that represents arrays with indices from 
n to m, inclusive. It should also support the following new messages. 


* Class method new should create a new, empty array with n = 1 and 
m = 0. 

* Instance method addlo: should decrease n by 1 and add its argument 
in the new slot. Instance method addhi: should increase m by 1 and 
add its argument in the new slot. Method add: should be a synonym 
for addlo:. 


* Instance method remlo should remove the first element, increase n 
by 1, and answer the removed element. Instance method remhi should 
remove the last element, decrease m by 1, and answer the removed el- 
ement. 


Each of these operations should take constant amortized time, as should at:. 


24. 


25. 


26. 


27. 


28. 


29. 


30. 


For ideas about representation, look at the implementation of this abstrac- 
tion using Molecule (Appendix T). 


Lists implemented by arrays. The ArrayList class from Exercise 23 could be 
used to implement List. 


(a) Estimate the space savings for large lists, in both the average case and 
the worst case. 


(b) Write an implementation. 
Complete class List. 


(a) Implement removeLast for class List. 


(b) Implement removeKey:ifAbsent: for lists. 


Fix at:put: on class List. If the index is out of range, the at: put: method 
on class List silently produces a wrong answer. What an embarrassment! 
Please fix it. 


(a) Supplement the existing implementation with an explicit range check. 


(b) Throw away the existing code, and in its place devise a solution that 
delegates the work to classes Cons and ListSentinel. 


(c) Compare the two solutions above. Say which you like better and why. 


Refactor keyed collections. Increase code reuse in class KeyedCollection by 
introducing a private method detectAssociation:ifAbsent: that takes two 
blocks as arguments. Then use the new method to implement other meth- 
ods. Explain why this change might be a good thing even if it makes the code 
harder to understand. Hint: What about implementations that use hash tables? 


Aggressive reuse can divide code into many small methods and distribute 
them over several classes. Understanding a nontrivial computation may 
then require understanding of each method and its specification, which can 
be challenging—but each individual method is simple, easy to understand, 
and easy to test. In light of this observation, argue whether your change to 
KeyedCollection is an improvement. 


Hash tables. Define a class Hash that implements a mutable finite map using 
a hash table. Objects of class Hash should respond to the same protocol as 
objects of class Dictionary, except that a Hash object may assume that the 
hash message may be sent to any key. A key object answers the hash mes- 
sage with an machine integer that never changes, even if the state of the key 
changes. Choose a suitable jsSmalltalk class to inherit from, and use the rep- 
resentation and the invariants from the hash table in Exercise 34, Chapter 9 
(page 598). 


Binary-search trees. Define a class BST that implements a mutable finite map 
using a binary search tree. Objects of class BST should respond to the same 
protocol as objects of class Dictionary, except that a BST object may assume 
that keys respond to the Magnitude protocol. 


Constant-time at:ifAbsent: for arrays. Class Array inherits at:ifAbsent: 
from SequenceableCollection. This implementation costs time linear in 
the size of the array. Without defining any new primitives, build a new im- 
plementation that takes constant time: 


(a) Using removeSelector:, remove the definition of at: from class Array, 
so it inherits at: from SequenceableCollection. 
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add: B 644 
do: B 644 
includes: B 644 
print 615 
space B 641 


(b) On class Array, implement at: ifAbsent: using primitive arrayAt and 
the other methods of class Array. 


31. An iterator for locations in shapes. In Section 10.1, examine the algorithm for 
drawing polygons and look at what kinds of intermediate data are allocated. 
Sending locations: to an object of class Shape allocates an intermediate list 
of locations, which is used in drawPolygon: on class Tikzpicture, then im- 
mediately thrown away. Eliminating this sort of allocation often improves 
Smalltalk and performance. 


objector iennation Class Shape doesn’t have to provide a list of the locations; it could equally well 


729 provide an iterator, with this protocol: 


locationsDo:with: symbols aBlock 
For each symbol s in the collection symbols, send 
(aBlock value: 1), where / is the location of the control point 
named by symbol s. If s does not name any control point, the 
result is a checked run-time error. 


(a) Extend class Shape with a locationsDo:with: method. 

(b) Suppose that locations: were eliminated, so that all client code had to 
use the locationsDo:with: method. What other classes would have to 
change, in what ways, to continue to draw polygons? 

(c) Is there a way to change the other classes so that no intermediate list 
(or other collection) is allocated? If so, explain what other intermediate 
objects have to be allocated instead. If not, explain why not. 

(d) If your answer to the previous part is “yes, the other classes can be 
changed,” then explain whether you prefer the new design or the orig- 
inal, and why. 


10.15.11 New magnitudes 


32. Characters as magnitudes. In full Smalltalk-80, a character is a Magnitude, but 
in Smalltalk, it’s not. Redefine class Char to be a subclass of Magnitude. 
To be sure it implements the full protocol for magnitudes, write unit tests. 


33. More magnitudes. In Smalltalk, the only interesting Magnitudes are Numbers. 
Don't stop at Char—define more Magnitudes! 


(a) Define Date as asubclass of Magnitude. A Date is given by amonth, day, 
and year. Define a + method on Date that adds a number of days to the 
date. This method should know how many days are in each month, and 
it should also know the rules for leap years (Dershowitz and Reingold 
1990, 2018). 

(b) Define Time asa subclass of Magnitude. A Time object represents a time 
on a 24-hour clock. Define a + method that adds minutes. 


10.15.12 Numbers 


34. Arithmetic overflow in Float. As defined in Section U.5.11, floating-point ad- 
dition might overflow. Re-implement floating-point addition so that it nei- 
ther overflows nor loses precision unnecessarily. For example, adding 0.1 
to 1 should lose no precision. Try these suggestions: 


* Make each exponent as small as it can be without overflowing. 


* Use the larger of the two exponents. 


35. 


36. 


37. 


38. 


Arithmetic overflow in Fraction. In class Fraction, could redefining < in 
terms of - reduce the possibility of overflow? Justify your answer. 


Mixed arithmetic with integers and fractions. This problem explores improve- 
ments in the built-in numeric classes, to try to support mixed arithmetic. 


(a) Use reflection to arrange the Fraction and Integer classes so you 
can add integers to fractions, subtract integers from fractions, mul- 
tiply fractions by integers, etc. That is, make it possible to perform 
arithmetic by sending an integer as an argument to a receiver of class 
Fraction. Minimize the number of methods you add or change. 


(b) Use reflection to change the Integer class so you can add fractions to 
integers—that is, use a fraction as an argument to a + message sent to 
an integer. This requires much more work than part 36(a). You might 
be tempted to change the + method to test to see if its argument is an 
integer or a fraction, then proceed. A better technique is to use double 
dispatch (Section 10.8.3, page 666): the + method does nothing but send 
a message to its argument, asking the argument to add self. The key is 
that the message encodes the type of self. For example, using double 
dispatch, the + method on Integer might be defined this way: 

723. (double dispatch 723)= 
(method + (aNumber) 
(aNumber addIntegerTo: self)) 


The classes Integer, Float, and Fraction would all then define meth- 
ods for addIntegerTo:. 


(c) Complete your work on the Integer class so that all the arithmetic oper- 
ations, including = and <, work on mixed integers and fractions. Min- 
imize the number of new messages you have to introduce. You may 
wish to use reflection to change or remove some existing methods on 
Integer and SmallInteger. 


(d) Finish the job by making Fraction’s methods answer an integer when- 
ever the denominator of the fraction is 1. 


Arbitrary-precision natural-number arithmetic. An object of class Natural rep- 
resents a natural number of any size; the protocol for natural numbers is 
shown in Figure 10.22 (page 653). Study the discussion of natural-number 
arithmetic in Appendix B (page S13). Then study the discussion of object- 
oriented implementations of natural numbers in Section 10.8.5 (page 669). 
Finally, implement natural-number arithmetic by completing class Natural, 
which is shown in Figure 10.27 (page 670). You might start by implementing 
= and < using the other methods of the class, which you can do independent 
of your choice of representation. 


Arbitrary-precision signed-integer arithmetic. Using a sign-magnitude repre- 
sentation, implement large signed integers as described in Section 10.8.3. 
Define whatever methods are needed to answer not only the large-integer 
protocol but also the Integer, Number, Magnitude, and Object protocols, 
except for div: and mod:. Focus on methods print, isZero, isNegative, 
isNonnegative, isStrictlyPositive, negated, +, *, and sdiv:. 


So that small-integer arguments can be passed to large-integer methods, use 
reflection to add an asLargeInteger method to class SmallInteger. 
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39. 


Transparent failover from machine-integer arithmetic to arbitrary-precision arith- 
metic. Use reflection to change the definition of class Small Integer such that 
if arithmetic overflows, the system automatically moves to large integers. 
Furthermore, make arithmetic between small and large integers work trans- 
parently as needed, and make small integers respond to the same sdiv: and 
smod: messages that large integers respond to. 


You will need the following primitives: 


+ Evaluating (primitive addWithOverflow self aSmallInteger ovBlock) 
computes the sum of the receiver and the argument aSmallInteger. 
If this computation overflows, the result is ovBlock; otherwise it is a 
block that will answer the sum. 


Evaluating (primitive subWithOverflow self aSmallInteger ovBlock) 
computes the difference of the receiver and the argument aSmallInteger. 
If this computation overflows, the result is ovBlock; otherwise it is a 
block that will answer the difference. 


Evaluating (primitive mulWithOverflow self aSmallInteger ovBlock) 
computes the product of the receiver and the argument aSmallInteger. 
If this computation overflows, the result is ovBlock; otherwise it is a 
block that will answer the product. 


These primitives require a level of indirection; instead of answering directly 
with a result, they answer a block capable of returning the result. This prop- 
erty is needed to arrange for the proper execution of the recovery code, but 
it makes the use of these primitives a bit strange. An example may help; this 
one includes the analog of the Smalltalk-80 code on page 705: 
724. (example use of primitives with overflow recovery 724) = 
(SmallInteger addSelector:withMethod: '+ 
(compiled-method (aNumber) (aNumber addSmallIntegerTo: self))) 
(SmallInteger addSelector:withMethod: 'addSmallIntegerTo: 
(compiled-method (anInteger) 
C(C(primitive addWithOverflow self anInteger 
{((self asLargeInteger) + anInteger)?) value))) 


You might be tempted to test your code against a table of factorials, but fac- 
torials are computed using only multiplication. Try Catalan numbers, which 
can be computed recursively using a combination of multiplication and ad- 
dition. 


10.15.13 Method dispatch 


40. 


41. 


Formal semantics for method dispatch. Judgment form m > c @ imp describes 
method dispatch (Section 10.10.1). This form isn’t described by proof rules, 
but it is implemented by function findMethod in chunk 690b. Using the im- 
plementation as a guide, write proof rules for the judgment. 


Method cache. Because Smalltalk does everything with method dispatch, 
method dispatch has to be fast. The cost of dispatch can be reduced by 
method caching, as described by Deutsch and Schiffman (1984). Method 
caching works like this: with each SEND form in an abstract-syntax tree, asso- 
ciate a two-word cache. One word gives the class of the last object to receive 
the message sent, and the other gives the address of the method to which the 
message was last dispatched. When the message is sent, consult the cache; 


if the class of the current receiver is the same as the class of the cached re- 
ceiver, then execute the cached method; no method search is needed. If the 
class of the current receiver is different, search for a method in the usual 
way, update the cache, and execute the method. 


Method caching saves time if each SEND in the source code usually sends to 
an object of a single class—which research suggests is true about 95% of the 
time. Adding a method cache made an early Berkeley Smalltalk system run 
37% faster (Conroy and Pelegri-Llopart 1982). 


(a) 


(b) 


(c) 


(d) 


10.15.14 


Extend the wSmalltalk interpreter with method caches. 


* Define a type classid whose value can uniquely identify a class. 
Since the class field of each class is unique, you can start with 
type classid = metaclass ref 

Add a field of type (classid * method) ref to the SEND form in the 
abstract syntax. This reference cell should hold a pair represent- 
ing the unique identifier of the last class to receive the message at 
this call site, plus the method found on that class. 


Change the parser to initialize each cache. As the initial class iden- 
tifier, define 


val invalidId : classid = ref PENDING 


Value invalidId is guaranteed to be distinct from the class field 
of any class. 

* Change function ev in chunk 689b to use the cache before calling 
findMethod, and to update the cache afterward (when a method 
is found). Consider defining a function findCachedMethod, whose 
type might be (classid * method) ref * name * class -> method. 


Add code to gather statistics about hits and misses, and measure the 
cache-hit ratio for a variety of programs. 


Find or create some long-running Smalltalk programs, and measure 
the total speedup obtained by caching. (Because the method cache 
does not eliminate the overhead of tracing, the speedup will be rela- 
tively small. You might want to suppress tracing by adding the defini- 
tion fun trace f =f ().) 


If a uSmalltalk program uses the setMethod primitive or any of the 
reflective facilities that copy methods, it could invalidate a cache. Ei- 
ther eliminate the primitive or correct your implementation so that ev- 
ery use of the primitive invalidates caches that depend on the relevant 
class. Don’t forget that changing a method on class C’ may invalidate 
not only caches holding C’ but also caches holding C’s subclasses. 
Measure the cost of the additional overhead required to invalidate the 
caches. 


Object-oriented profiling 


42. Profiling. Implement a message-send profiler that counts the number of 
times each message is sent to each class. Use this profiler to identify hot 
spots in the simulation code from Appendix E. 
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Afterword 


It’s a magical world, Hobbes, ol’ buddy. . . let’s go exploring! 


Calvin 


CALVIN AND HOBBES © 1995 Watterson. 
Reprinted with permission of ANDREWS 
MCMEEL SYNDICATION. All rights reserved. 


Congratulations! You now have some solid skills using functions, types, modules, 
objects, and more. You also have a cognitive framework that you can use to learn 
new programming languages, and if you’re like my students, you'll be pleasantly 
surprised at how broadly your skills apply. Now you get the dessert menu. As your 
server, I recommend some tasty treats: languages that are superlative, unusual, or 
popular. Many are widely recognized as interesting or important, and some are just 
to my personal taste. Together, they offer a variety of jumping-off points, ranging 
from younger, less proven ideas to fashionable ideas drawn from the headlines. 


TYPEFUL PROGRAMMING 


If you like types, try Haskell. Haskell is a pure functional language: even I/O inter- 
actions are represented as values with special I0 types. And Haskell is pushing new 
type-system ideas into the mainstream far faster than any other language. By the 
time this book is published, Haskell will have cool new features I haven’t even heard 
of yet. Start with the basics: type classes and monads (Lipovaca 2011). Definitely 
try QuickCheck (Claessen and Hughes 2000; Hughes 2016), which uses Prolog-like 
inference rules to do amazing things with random testing. And don’t overlook 
QuickCheck’s shrink function—although it’s barely mentioned in the original pa- 
per, it’s a crucial part. After that, explore what Stephanie Weirich and Richard 
Eisenberg are doing. 

Dependent types can express many interesting properties of data. The classic ex- 
ample uses types to keep track of how long a list is, without losing polymorphism. 
Interesting dependently typed languages include Idris and Agda. The Epigram lan- 
guage is less active, but its papers and tutorials are very good (McBride 2004). 

Types are also being used to manage memory: types can enable safe, fast sys- 
tems programming without (much) garbage collection. Look into Rust, and check 
out earlier work on Cyclone (Grossman et al. 2005). 


PROPOSITIONS AS TYPES 


Early in the twenty-first century, proofs about correctness start with the principle 
of propositions as types. 

Propositions in classical logic correspond to types in a functional language (See 
Table AW.1 on the next page). In logic, symbols A and B represent propositions; 
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Table AW.1: Elements of classical logic with their counterparts in types 


Proposition Type 


Conjunction ANB AxB_ Pair 
Disjunction AVB A+B Sum 


Implication ADB A-B Function 
Complement aA = (no counterpart) 
Quantification Va.A Va.A Polymorphism 
Truth “lf 1 Unit 


Falsehood ath void Uninhabited 


in language, A and B represent types. Derivations in logic also correspond to 
derivations in type theory. For example, in logic, A \ B is proved by proving both 
Aand B. And in language, a term of type A x B is introduced using terms of types 
Aand B. The derivations end in analogous steps; and-introduction corresponds to 
pair-introduction: 


TEA TEB Tke:A Thke:B 
TFKAAB TF (e1,€2): Ax B 


In logic, symbol T represents a theory, and it lists all the propositions whose truth 
is assumed. In language, symbol I represents a typing context, and it lists all the 
types whose inhabitation is assumed. (The context gives a variable of each type, 
and the type is inhabited by the value of that variable.) 

As another example, in logic, A > B (implication) is proved by assuming A, 
then using the assumption of A to prove B. In language, a value of type A > Bis 
created by defining a function that takes a value of type A, then uses the value to 
produce a result of type B. Again, the derivations end in analogous steps: 


T,AFB T,2:Atre:B 
TFADB ThkArw:A.e:A>B 


Almost every classical logical connective corresponds to a type constructor, ex- 
cept one: logical complement. Programming-language types correspond to what 
is called constructive or intuitionistic logic, which doesn't have complement. Like 
Prolog (Appendix D), constructive logic concerns itself not with what is true, but 
with what is provable. And the provable is the computable. 


+ A type in a programming language corresponds to a proposition in logic. 


+ A term in a programming language corresponds to a proof in logic. But cau- 
tion! For the proof to be good, the term must evaluate to completion. So such 
proofs are written using languages in which all evaluations are guaranteed to 
terminate. Such languages resemble one that you already know: if val-rec 
and letrec are removed from Typed Scheme, then the evaluation of any 
well-typed expression is guaranteed to terminate. 


The propositions-as-types principle has led to a host of automated theorem 
provers that are also programming languages. In the late 1980s, this idea was pop- 
ularized by Nuprl (Constable et al. 1985); in the early 2020s, much work is done 
in Coq/Gallina. These systems are generally considered “proof assistants” rather 
than “programming languages,” but the line is blurry; for example, similar proofs 
can be written in the dependently typed languages Agda and Idris. 


For deep mathematical background on the connections between propositions 
and types, as well as connections to decidability and models of computation, read 
Wadler (2015). To use your knowledge of functional programming to start proving 
theorems for yourself in Coq, tackle Software Foundations (Pierce et al. 2016). 


MORE FUNCTIONS 


Among functional languages, OCaml includes some interesting design experi- 
ments, and it’s cool among systems programmers, financial engineers, and many 
academics. Clojure brings Lisp ideas to the Java Virtual Machine, with interesting 
support for multithreading (Hickey 2020). There’s also Haskell of course, and you 
ought to play with Racket, which pushes Scheme and macros to the limit. Racket 
ist just a language or a system; it’s a factory for making new languages (Flatt 2012). 


MORE OBJECTS 


Objects are everywhere. If you know Smalltalk, you almost know Ruby, but the pro- 
gramming environment is very different. The difference is this: Squeak Smalltalk 
gives you a lovely graphical programming environment, but it’s not really con- 
nected to anything else on your computer. It’s like having a fabulous house— 
on Mars. Ruby gives you the same fabulous language, but right next door. Or you 
could try Pharo, which nicely integrates the Smalltalk language and programming 
environment into a modern operating system. 

Then there are the hybrids. Objective C seems most faithful to Smalltalk’s vi- 
sion. If you prefer complexity to simplicity, you’re ready for Python. Add more 
static types and you have Java, C#, C++, Swift, and many other popular languages. 

More interesting languages provide objects with prototypes instead of classes. 
Self is the original and a great place to start (Ungar and Smith 1987). Once you have 
the ideas, you can apply them in JavaScript, whose good parts combine ideas from 
Scheme and Self (Crockford 2008), and in Lua, a great scripting language mentioned 
below. 


FUNCTIONS AND OBJECTS, TOGETHER 


Lots of designers have put functions and objects together in a single language. 
OCaml was an early player, combining what was then known about objects and 
functions into a single system. More ambitious efforts include Scala and F#, each 
of which integrates an existing object-oriented type system (respectively the Java 
Virtual Machine and the Microsoft Common Language Runtime) with ideas from 
functional programming. 


FUNCTIONAL ANIMATION 


A functional reactive animation is a program that implements animation or even 
interaction using pure functional code. A very nice exemplar is the Elm program- 
ming language. It runs right in your web browser, and there’s a great community. 


SCRIPTING 


My favorite scripting language is Lua. It is lean, fast, and simple—what Scheme 
might have been if it had used Pascal’s syntax, if it had no macros, and if its cen- 
tral data structure were the mutable hash table, not the cons cell. Lua tables work 
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both as arrays and as hash tables, and they also serve as (prototype-based) objects! 
Lua ships with a nice, simple string-processing library. And Lua is an embedded lan- 
guage: it can easily talk to any library written in C, and it can be dropped into any 
C or C++ program and be used for scripting and control. For example, Lua scripts 
make up most of the code in Adobe Lightroom. Lua is described by a fine book 
(Ierusalimschy 2016) and a nice paper about its design and history (Ierusalimschy, 
de Figueiredo, and Celes 2007). 


PARALLEL AND DISTRIBUTED COMPUTATION 


If you want programs to run in parallel, and especially if you want programs to 
run distributed over multiple computers, try Erlang. It’s got a simple, effective 
message-passing model of concurrency, plus great ideas about recovering from 
failure—and if you're distributing computations, you have to worry about failure. 
And Erlang is easy to pick up; it uses Prolog’s syntax and data, but its computational 
model is a lot like Scheme. 

For more message-passing concurrency, but with a very different flavor, try Go. 
Go’s primary mission is to “make systems programming fun again,” and the concur- 
rency model is sweet. 


ONE WEIRD, COOL, DOMAIN-SPECIFIC LANGUAGE 


The language Inform7 is designed for writing interactive fiction, or, as we used 
to call it, text adventure games (ATTACK DRAGON WITH BARE HANDS and all that). 
An Inform7 program doesn’t even look like a program; it looks like a cross between 
a manual and a text adventure game. And Inform? ships with a really interesting 
interactive programming environment. I’m still wondering exactly what the ab- 
stract syntax of Inform7 is—or if it even uses an abstract syntax—but if you have 
any interest in this domain, you have to try it. 


STACK-BASED LANGUAGES 


Chapter 3 uses an evaluation stack to implement pzScheme-+, but the stack is hid- 
den from the programmer. Why not expose it? The classic stack-based language is 
Forth, which gets extraordinary power from a minimal design. A Forth environ- 
ment can fit in a few kilobytes of RAM, and Forth has been used on many embedded 
systems. For a nice example, check out the Open Firmware project. 

If you like your stacks with a few more data types, write some PostScript. Sweep 
away all the primitives related to fonts and graphics, and you'll find a very nice 
stack-based language underneath. Even the current environment is represented 
as a stack, and by manipulating it, you can quickly change the meanings of names 
en masse. 


ARRAY LANGUAGES 


While John McCarthy was developing his list-based language, Ken Iverson (1962) 
was developing the array-based language APL. (Both later received Turing Awards.) 
Derived from notation used at the blackboard, APL evolved into an important lan- 
guage at IBM, where it was written by using a special typeball on IBM’s Selectric 
typewriter. At a time when almost all IBM’s mainframe business meant program- 
ming with punched cards, APL gave IBM a powerful interactive option. APL orig- 
inated many ideas that were fully developed in functional languages, including 


maps, filters, and folds. You can also check out Iverson’s successor language, J, 
which may look like line noise, but which runs on ordinary computers. Both APL 
and J enable you to define array functions that are polymorphic not just in the size 
of an array, but in the number of its dimensions. This behavior can be explained 
using a modern, static type system of the sort you have mastered (Slepak, Shivers, 
and Manolios 2014). 


LANGUAGES BASED ON SUBSTITUTION 


When you instantiate a polymorphic type in Typed zScheme, you have to imple- 
ment capture-avoiding substitution (Section 6.6.7, page 371). That same substi- 
tution is the computational engine behind lambda calculus. Substitution is hard 
to get right, hard to reason about, and inefficient. So it’s astounding how many 
eminent computer scientists—and uneducated hackers—have designed languages 
around substitution. Notable examples include TeX (used to typeset this book); 
Tcl/Tk (used to make GUIs quickly); the POSIX, Bourne, Korn, and Bourne Again 
shells (used to script Unix systems), and PHP (used to make web pages). Each of 
these languages does something well, but for general-purpose programming, they 
are no fun. For Facebook, PHP is so much not fun that Facebook has developed a 
language called Hack, which embraces legacy PHP code while adding static types— 
a real language-design feat. 

A related language, based more on string rewriting, was TRAC (Mooers 1966); 
if you’re intrigued by text macros, as opposed to syntax macros, it’s worth a look. 
A clone of TRAC, MINT (for MINT Is Not TRAC), shipped as the extension language 
of Russ Nelson’s Emacs clone, Freemacs. 


STRING-PROCESSING LANGUAGES 


Domain-specific languages for string processing are in decline, but Icon is worth 
looking at: it uses a string scanning technique that relies on a backtracking eval- 
uation model just like the one used in Prolog. Unlike regular expressions, string 
scanning can be extended with custom string-processing abstractions, and they 
compose nicely with the built-in abstractions. 

For historical interest only, I recommend Awk, which was important early and 
for a long time, although it is both dominated and superseded by later languages. 
The code I once wrote in Awk I now write in Lua. 

Also relegated to historical interest is Perl, which has first-class functions like 
Scheme, multiple name spaces like Impcore, and string processing based on regu- 
lar expressions. Perl has become unfashionable, but there is plenty of legacy Perl 
code out there—to which your skills apply. 


CONCLUSION 


It really is a magical world. Go exploring! 
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tricolor marking, 290 (Garbage collection) 

type, 385 (type systems), 442 (nano-ML) 

type abbreviation, 320 (szScheme in ML), 
502 (j1ML) 

type abstraction, 385 (type systems) 

type application, 385 (type systems) 

type checker, 385 (type systems) 

type constructor, 385 (type systems) 

type inference, 442 (nano-ML) 

type scheme, 442 (nano-ML) 

type system, 385 (type systems) 

type variable, 320 (uScheme in ML) 


undelimited continuation, 

245 (uwScheme-+) 
unification, 442 (nano-ML), S97 (j:Prolog) 
unreachable, 290 (Garbage collection) 
user-defined type, 502 (uML) 


value constructor, 320 (jsScheme in ML), 
502 (JuML) 
value semantics, 174 (Scheme) 


work per allocation, 290 (Garbage collec- 
tion) 


Key words 
and phrases 
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A (automatically generated function in 
identifier cross-reference), 39 
abbreviations, type, 529 
abstract classes, 622, 624, 656-662, 708 
Collection, 642 
Integer, 664 
LargeInteger, 669 
Number, 663 
abstract data types, see abstract types 
abstract machine(s), 30, 67 
further reading, 246 
Impcore, 30 
for implementation, 246 
pScheme, 144 
puScheme-+, 211 
Smalltalk, 678-679 
representations 
yLSmalltalk, 686-687 
in semantics, 211 
abstract-machine semantics, 244 
abstract syntax, 14, 15, 67 
exceptions, 589 
Impcore, 27-28 
LML, 485-486 
uScheme (in ML), 306-307 
Scheme (in C), 144-145 
pScheme-+, 225-226 
pScheme-+ stack frames, 225-226 
Smalltalk, 687-688 
nano-ML, 404-405 
Typed Impcore, 332-333 
Typed yScheme, 361 
abstract-syntax trees, 27-28 
in C, 41-43 
abstract types, 455, 525, 538, 585 
in C, 39 
as components of modules, 538 
design choices, 580-583 
equality and, 634 
examples, 526 
and exceptions, 583-584 
in Java, 707 
limitations, 585 
objects vs, 625-627 
proofs of correctness, 588 
in real languages, 580-583 


749 


abstraction(s), 527, 528, see also data ab- 
straction 
immutable, 545 
mutable, 545 
syntactic, see macros 
abstraction functions, 545, 549 (defined), 
586, 708 
circular lists, 673 
complex numbers, 551 
data structures, typical and, 549- 
551 
dictionaries, 549 
examples, 552 
natural numbers, 670, 671 
priority queues, 550, 552 
sets, 548 
two-dimensional points, 551 
abstraction, functional, 36 
access paths, 561 (defined) 
absolute, 559 
environment lookup, 574 
of modules or components, 559 
pseudo-bindings, 563, 574 
relative, 575 
accessor(s), see observers 
accessor functions for records, 107 
accumulating parameters, 99-101 
ad hoc polymorphism, 132, 544, see also 
overloading 
algebraic data types, 317, 501 
compile-time checks, 499-500 
extensions, 503 
generalized, 503 
in UML, 466-476 
in Molecule, 535 
origins, 502 
polymorphic, 462-463 
in real languages, 499-501 
recursive, 463-464 
algebraic laws, 98 
association lists, 106, 112 
binary-tree nodes, 109 
in calculational proofs, 115 
case expressions, 476-477 
continuation-passing style and, 
138 
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algebraic laws (continued) 
currying and uncurrying, 126 
equality of S-expressions, 104 
finite maps, 112 
further reading, 175 
has? (wScheme function), 103 
higher-order list functions, 130 
if expressions, 112 
and imperative features, 403 
insertion sort, 101 
length of a list, 98 
length of appended lists, 115 
list append, 99 
list insertion, 101 
list primitives, 111 
list reversal, 100 
membership in S-expressions, 103 
notation for lists, condensed, 99 
operator classifications and, 111- 
112 
pair types, 349 
product types, 349 
proofs of, 114, 115 
set functions, 105 
simplifying code with, 113 
solving conjunctive normal form, 
141, 142 
soundness, 65 
in specifications, 547, 548 
substitutions, 409-410 
testable properties as, 110 
tree-node functions, 109 
tuple types, 349 
uses, 175 
algebraic specification, 547, 548 
allocation, 259 
in functional languages, 205 
implementations, 162 (jiScheme), 
266 (uwScheme+) 
interfaces, 154 
in uScheme-+, 266 
mutability and, 545 
in procedural languages, 206 
allof, 541, 552, 555 
alpha-conversion (renaming) 
type variables, 368-369 
and (A, type intersection), 564 
and, meaning in ML, 303 
answer(s), 708 
to messages, 610 (defined) 
answer (verb form) 
in Smalltalk, 612 
answer types 
in continuation-passing style, 138 
APIs, 527, 586 
examples, 531-532 


append, 99 (yScheme), 475 (UML) 
proof of laws, 114 
applicative languages, 402 
apply primitive (exercise), 198 
arguments, variable number of, 169 
arithmetic, multiprecision, see multi- 
precision arithmetic 
arity 
Smalltalk message names, 627 
primitives, 313 
arrays 
associative, see finite maps 
implementation (uSmalltalk), 661- 
662 
semantics, 345 
syntax, 343-345 
type checking, 348 
types for, 343 
typing rules, 346-348 
arrow types 
typing rules, 348 
ascriptions 
of a module type to a module, 564 
in Standard ML, 441 
type checking, 564 
assignment 
to Boolean variables, 138 
satisfying a Boolean formula, 138 
assignment (syntactic form set) 
implementations 
Impcore, 49 
pScheme, 156 
uUScheme-+, 230 
operational semantics 
Impcore, 34 
pScheme, 145 
Smalltalk, 680 
small-step semantics, 217 
typing rules 
Typed Impcore, 335 
Typed juScheme, 363 
association lists, 105-107, 646, S73 
algebraic laws, 106, 112 
attributes, 105 
continuations and, 136-137 
equality, 132-133 
in full Scheme, 169 
keys, 105 
sets of, 132-135 
associative arrays, see finite maps 
ASTs, see abstract-syntax trees 
@ (instantiation), 352, 358, 412 
examples, 358 
implicit, 413 
typing rules, 365 
atoms, 172, S95 
in wScheme, 92 
in Prolog, S43 


autognostic principle, 626, 708 
automatic instantiation, 409 
automatic memory management, 288 
benefits, 257 
performance, 260 


B (basis function in identifier cross- 
reference), 39 
backtracking 
using continuation-passing style, 
138-143 
visualizations, 139 
Backus-Naur Form, 17 
base types, 343 
Typed Impcore, 333 
basis, 26 (defined), 67 
Impcore, 29 
initial, see initial basis 
Typed Scheme, 382 
bearskins, 588 
begin 
operational semantics 
Impcore, 35 
pScheme, 149 
Smalltalk, 681 
syntactic sugar, 167 
typing rules 
nano-ML, 413 (nondeterministic), 
446 (constraint-based) 
Typed Impcore, 336 
Typed Scheme, 363 
behavior(s), zSmalltalk 
representation, 687 
semantics, 678-679 
behavioral specifications, 527 
examples, 529, 547 
behavioral subtyping, 627, 708, 713 
big-step semantics, see operational se- 
mantics 
bignums, see large integers 
binary operations 
on abstract types, 555-557 
on objects, 662-673 
primitives, embedded as, 313 
binary search trees 
exercises, 508-509 
representation invariants, 550 
binary trees 
algebraic laws, 109 
encoded as S-expressions, 109-110 
exercises, 508-509 
inference rules, to define, 109 
pScheme, 109-110 
traversals 
breadth-first, 118-120 
inorder, 181 
level-order, 118-120 
postorder, 181 


binary trees (continued) 

traversals (continued) 

preorder, 110 

binding(s) 

access paths, 563, 574 

in Molecule type-checking envi- 

ronments, 563 

binding occurrences 

type variables, 371 (defined) 
black magic, decision procedure for, $45 
black objects, 261 

in copying collection, 273 

examples, 275 

in mark-sweep collection, 269 
blocks (wSmalltalk), 618, 627-629, 708 

bootstrapping, 698 

closures and, 618 

evaluation, 691 

operational semantics, 681 

protocol, 630, 638-641 
BNF, 17 
Boolean(s) 

Church encoding, 655 

pSmalltalk, 630 

bootstrapping, 697-699 

boolean?, 92 
Boolean classes 

implementations, 655 

protocol, 639 
Boolean operators, short-circuit, 164- 

165 

Boolean satisfiability, 138-139 

solver, 139-143 
bootstrapping, jzSmalltalk 

blocks, Booleans, literals, 698-699 
bound occurrences 

of type variables, 371 
bound type variables, 371 (defined) 
bound variables, 315-317 
brackets 

square vs round, 117 

as tokens, 17 
breadth-first traversals, 118-120 
break, 202, 206-207 (examples) 

real implementations, 239 
Brown, Troy, 635 
bugs, Scheme, false reports of, 154 
Byrd boxes, 139, 175 


C programming 
advantages and disadvantages, 301 
conventions, 39-40 
interfaces, 40 
ML programming vs, 314-315 
scope rules, 74 
static variables, 124 

caar, cadr, cdar, and so on, 96 
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calculational proofs, 114-116, see also 
equational reasoning 
form, 114 
organization, 115 
calculus 
as a form of abstract machine, 241 
call/cc, 172, 242-243, 244, 247, 255 (ex- 
ercises) 
call stacks, 65, 239, 244, 288 
canvases (j4Smalltalk), 618-619 
capitalization 
in C programs, 39-40 
of value constructors, 469-471 
capture 
of type variables, 369, 373 
in type-lambda, 365 
capture-avoiding substitution, 165-167, 
365, 373-375 
implementations, 374-375 
specification (rules), 374 
for type variables, 365 
type-lambda and, 377-378 
car, 94,172 
implementations, 162 
operational semantics, 151 
origin of name, 94 
cascade, message (Smalltalk-80), 706 
case expressions, 457, 459, 501 
algebraic laws, 476-477 
benefits, 501 
equational reasoning, 476-479 
evaluation, 490-494 
examples, 459-466, 475-476 
operational semantics, 490-494 
semantics, informal, 468-469 
type inference, 495-499 
typing rules, 349, 495-496 (non- 
deterministic), 497- 
499 (constraint-based) 
catch (in jskScheme+), 204 
catching an exception, 208 
categories, syntactic, see syntactic cat- 
egories 
cdar, caar, cadr, and so on, 96 
cdr, 94, 172 
operational semantics, 151 
origin of name, 94 
CESK machine, 243, 246 
characteristic functions (of sets), 187 
check~assert, 23, 26 
check-error, 23, 25 
check-expect, 23-26 
in “Smalltalk using =, 635 
check-principal-type, 402 
check-type, 402 
checked run-time errors, 40 
Church encodings 
Booleans, 655 


Church-Rosser theorem, 246 
Circle (jSmalltalk class), 620 
circular lists, 673 
abstraction function, 673 
representation invariants, 673 
class(es), 610, 708 
abstract, 622 
creation, 695 
definitions, 614 
modules vs, 588 
representations, 686, 694-695 
Class (ySmalltalk class), 696-697 
class Collection, 656-658 
class definitions 
operational semantics, 685 
class hierarchies 
collections, 642 
integers, 651 
numbers, 649 
Smalltalk-80, 704-707 
class instance variables 
Smalltalk-80, 704 
class List, 674-677 
class Magnitude, 656 
class Metaclass, 696-697 
class methods, 614, 708 
class Object, 696 
class objects, 630 
Class protocol, 638 
class protocols, 613 
class True, 655 
class UndefinedObject, 696 
class variables 
Smalltalk-80, 704 
classifications 
of operators, 111-112, 546 
clausal definitions, 318, 480 (defined), 
501, 516 
benefits, 501 
examples, 480-482 
clauses (Prolog), S95 
client code, 526 (defined), 527, 530, 586 
closing 
over free type variables, 414 
closures, 122-125, 172 
application semantics, 147 
further reading, 175 
implementation, 122-124 
in uSmalltalk, 691 
in operational semantics, 147, 681 
representations 
C, 152 
nano-ML, 405 
semantics, 147-149 
static scoping and, 148 
CLU, 526 
further reading, 588 


CLU (continued) 
mutable types vs immutable types, 
545 
program correctness and, 585 
CNF,, see conjunctive normal form 
code chunks, 39 
coerce: method, 663 
coercions (jsSmalltalk), 667-669 
collection(s), 708 
examples, 645 
implementations, 656-662 
inheritance, 649 
Smalltalk protocols, 642-649 
Collection (jSmalltalk class), 656-658 
collection hierarchies, 642 
Smalltalk-80, 705-706 
Collection protocol, 643, 644 
coloring invariant, 261 (defined) 
Common Lisp, 89, 174, 713 
CommonLoops, 713 
commutative diagrams, 477 
compilation, 68 
of pattern matching, 500-501, 503 
compiling with continuations, 247 
complex operations, 555-557, 662-673, 
709 
examples, 666 
components of modules, 528 (defined) 
declarations of, 538 
exported, 538 
of intersection types, 541 
nested modules, 539 
public, 538 
strengthening, 570 
types, 538 
values, 538 
composition 
of functions, see function composi- 
tion 
of substitutions, 410-411 
conclusions 
in inference rules, 31 
concrete syntax, 14, 15, 69 
curried functions, impact on, 126 
exceptions, 589 
Impcore, 17-19 
Impcore vs C, 12 
UML, 467 
pScheme, 92, 93 
Smalltalk, 627-629 
rationale, 611 
Molecule, 535 
core layer, 536 
module layer, 537 
nano-ML, 404 
partial application, impact on, 126 
Smalltalk-80, 702-704 
Typed Impcore, 330-331 


concrete syntax (continued) 
Typed Scheme, 352, 353 
cond (Scheme form), 163-164 
conditional expressions 
algebraic laws, 112 
implementations 
puScheme-+, 230-231 
method dispatch vs, 623, 654-656 
object-oriented programming, 
deprecated in, 655 
operational semantics 
Impcore, 34 
uScheme, 149 
small-step semantics, 217-218 
type inference, 413, 418, 421 
typing rules 
nano-ML, 413 (nondeterminis- 
tic), 418 (explicit substitutions), 
421 (constraints) 
Typed Impcore, 335 
Typed jsScheme, 363 
conjunctions, 420 
constraint solving, 429 
conjunctive normal form, 139 
representation (uScheme), 140 
cons, 94, 172 
implementations, 161, 473 
operational semantics, 151 
origin of name, 94 
cons cell, 94, 95 (defined) 
Cons protocol, 675 
constraint(s), type-equality, 441 
grammar, 420 
implementations, 436 
trivial, 420 
in type inference, 420-428 
typing judgment, 420 
unsolvable, 424 
constraint satisfaction, 428 (defined) 
constraint solving, 418, 428-431, 441 
conjunction, 429 
examples, 431 
implementations, 436-437 
simple type equality, 429-430 
constructed values, 457 (defined), 501 
UML, 457 
Molecule, 534 
“constructor” 
pitfalls as a technical term, 111 
constructor(s), 111 
algebraic data types and, 457 
of Molecule values, 533 
names for abstract syntax, 42 
smart (in binary tries), 513 
constructor functions 
for records, 108 
contexts, evaluation, see evaluation con- 
texts 
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continuation(s), 136-138, 244 
blocks in Smalltalk as, 640 
compiling with, 247 
defined by evaluation context, 242 
delimited, 243, $358-359 
entering, 242 
exceptions and, 209-210 
failure, 136, 139, $239 
first-class, 242 
further reading, 246, 247 
in real languages, 242-243 
solutions, finding with, 142 
success, 136, 139 
undelimited, 243, 245 

continuation-passing style, 138-143 
for backtracking, 138-143 
direct style vs, 138 
further reading, 175 
identifying, 138, 170 
in Smalltalk, 610, 640 
in Smalltalk conditionals, 655 

continue, 202 
examples, 206-207 
real implementations, 239 

contravariance 
of function arrow in subtyping, 

606 

control (control operator), 247 

control flow, 201 
using continuations, 136-138 

control operators, 201-202, 206-210, 

244, 248-249 (exercises) 
big-step judgment forms, 677 
in big-step semantics, 679 
break, 202 
continue, 202 
control, 247 
long-goto, 204 
long-label, 204 
in uScheme-+, 202-204 
Smalltalk return, 677 
operational semantics, 210, 221- 

222 
prompt, 247 
in real languages, 239-240 
reset, 247 
return, 202 
shift, 247 
throw, 202 
try-catch, 204 

conventions, coding 
C, 39-40 
ML, 301-303 

CoordPair 
implementation, 615 
protocols, 613 

copying garbage collection, 271-279 
C code, 276-278 


copying garbage collection (continued) 
examples, 274-276 
in uScheme-+, 276-278 
performance, 278-279 
copying phase 
in uScheme-+ garbage collector, 
273 
core languages, 26, 162, 214 
layer in Molecule, 534 
in Scheme, 120 
Core puScheme-+, 214 
operational semantics, 215-223 
cost models of abstractions, 546 
crash, Scheme, causes of, 154 
creators (class of operations), 111 
introduction forms and, 347 
in protocols, 614 
creators, producers, and observers, 111- 
112 
type systems and, 347 
curried functions, 125-127 
concrete syntax and, 126 
curried modules, 575 
Curry-Howard isomorphism, 347, 727- 
729 
currying and uncurrying, 125-127 
algebraic laws, 126 
higher-order functions, 126 


Darcy, Lord, investigator for the Anglo- 
French empire, S45 
data abstraction, 455, 525, 586, 709 
benefits, 525 
binary operations and, 662-673 
closed systems and, 626 
design, 545-554 
equality and, 634 
examples, 525-526, 546-548 
further reading, 587 
in object-oriented languages, 625- 
627 
open systems and, 626 
data definitions 
UML, 466, 471-472 
typing rules, 487-489 
database (of Prolog clauses), S46 
datatype definitions, see also data defini- 
tions 
desiderata, 457 
generativity, 472 
UML, 471-473 
typing, 471-473 
De Morgan’s laws 
for exists? and al1?, 131 
in solving Boolean formulas, 189 
dead objects, 289 
dead variables, 289 


debugging 
closures (jsScheme), S331 
garbage collectors, 280-283 
by tracing calls and returns, 198 
by tracing evaluation, 224 
by tracing message sends, 640, 641 
decidability of type inference, 401 
declarations 
of exported components, 538 
of manifest types, 530 
syntactic category of, 16 
define 
desugared into lambda, 120 
explained, 22 
in full Scheme, 169 
operational semantics 
Impcore, 38 
pScheme, 152 
typing rules 
nano-ML, 416 (nondeterministic) 
Typed Impcore, 337 
Typed Scheme, 366 
definition(s) 
class, 614 
extended, 18, 24-26 
Impcore, 27 
implementations of, 159-160 
syntactic category of, 16 
true, 18 
definition modules, 528, 581 
definitional interpreters, 69 
degenerate type schemes, 414 
delegation, 709 


in the implementation of Set, $563 


delimited continuations, 243, 244, S358- 
359 
further reading, 247 
denotational semantics, 246 
dependent function types, 541 
dependent types, 383, 727 
derivations, 56 
construction (how to), 58-59 
validity, 57-58 
desugaring, 68 (defined) 
define, 120, 152 
do-while, 66 
let, let*, letrec, 163 
val-rec, 396 
while*, 66 
dictionaries, see finite maps 
direct style, 138 
continuation-passing style vs, 138 
dispatch, dynamic, see method dispatch 
divergence, 245 
do: (Smalltalk method), 642-645, 656 
examples, 617, 622, 657 
return within, 657 


domains 
of Molecule type-checking envi- 
ronments, 563 
of substitutions, 410 
dot notation, 528 
double dispatch, 666-667 
duck typing, 627, 708 
dynamic dispatch, see method dispatch 
dynamic scoping, 148 
dynamic typing, 327 


eager evaluation, 241 
EBNF, 17, S9-10 
effects, 110 
either (elimination form for sum 
types), 350 
elaboration, 452 (exercise), 573 (defined) 
exports, 573 
generic-module types, 573 
intersection types, 573 
UML, 489 
module types, 564, 571-574 
module-arrow types, 573 
Molecule rules, 572 
operator overloading and, 577 
overloading (Molecule), 576 
types (Molecule), 564, 571-574 
elimination forms, 347, 384, see also in- 
troduction and elimination 
forms 
exporting modules, 540 
generic modules, 541 
quantified types, 358 
elimination rules, 345 (defined) 
template, 346 
embeddings, 308, 318 
of functions, 312-314 
of lists, 308 
of ML primitives into wScheme 
primitives, 312 
projections and, 308-309 
of Booleans, 308 
of integers, 308 
encapsulation, 586, 615 
environments, 28-29, 69 
copying, 144 
global variables (Impcore), 28 
global variables (uwSmalltalk), 678 
Impcore, 28 
implementation for Impcore, 54- 
55 
interface, 153 
lookup in Molecule, 574-576 
uScheme, 144 
representation in ML, 304-305 
typing 
Molecule, 562 (defined), 563 
nano-ML, 435 
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environments (continued) 
typing (continued) 
Typed juScheme, 361 
equality 
algebraic laws, 104 
of association lists, 132-133 
in C, 633 
of collection elements, 646 
data abstraction and, 634 
exercises, 718 
in full Scheme, 633 
in Scheme, 633 
in OCaml, 634 
overloading, 543 
polymorphic, 633 
of S-expressions, 104 
in Standard ML, 633 
syntactic form for (Typed Imp- 
core), 332 
of types (pitfalls), 332 
typing rules (for Typed Impcore), 
336 
equality constraints, see type-equality 
constraints 
equality types (Standard ML concept), 
633, $217 
equational reasoning, 113-116, 183 
with case expressions, 476-479 
equivalence 
identity vs (in collections), 646 
LSmalltalk, 635 
observational, 634 
of types, see type equivalence 
erasure (of types), 380 
Erlang pattern matching, 499 
error(s) 
categories of, 13-14 
run-time, 40, 47 
syntax, 47 
:error exception, 208-209 
evaluation, 69 
block, 691 
case expressions, 468-469 
eager, 241 
Impcore definitions, 22-23 
Impcore expressions, 20-22 
lazy, 241 
message sends, 689-690 
pSmalltalk literals, 691 
Smalltalk primitives, 692-693 
modules, 541-542 
Molecule, 537 
overloading (Molecule), 577 
polymorphism and, 380 
return (uwScheme-+), 237 
return (wSmalltalk), 689 
stack-based, 212-213, 227-239 
strict, 241 


evaluation (continued) 
tracing, 224-225 
Typed Scheme, 380 
evaluation contexts, 202, 241, 245 
stack frames and, 242 
evaluation order, 242 
evaluation stacks, 210-213, 245, 289, 730 
analogs in real languages, 239 
exercises, 250 
instrumentation, 224-225 
interface to (uwScheme-+), 224 
memory management and, 229- 
230 
evaluators, 69 
case expressions, 492-494 
Impcore, 48-54 
pScheme (C), 154-160 
puScheme (ML), 309-312 
pSmalltalk, 688-694 
exceptions, 207-208, 318, 583 
abstract types and, 583-584 
catching, 208 
continuations and, 209-210 
examples, 208-209 
implementations, 208, 246 
raising, 207, 583 
in real languages, 240, 583 
syntax, 589 
throwing, 207 
execution, see evaluation 
exhaustive pattern matches, 318 
checks for, 499 
existentially quantified types, 503 
from algebraic data types, S25 
export lists, 538 
exported components, 538 
exported names, 526, 527 
exporting modules, 539 (defined) 
exports module types 
elaboration, 573 
expression(s) 
syntactic category of, 16 
type-level, 352, 357 
expression-oriented languages, 17, 69 
Extended Backus-Naur Form, 17, S9-10 
extended definitions, 18, 24-26 


facts (in Prolog), $45, $96 
failure continuations, 136, 139 
in withHandlers, S239 
filtering, 172 
examples, 206 
higher-order functions, 127 
methods, 645 
visualizations, 129 
find 
algebraic laws, 106 
using continuations, 136-137 


finite maps, 105 
algebraic laws, 112 
first-class functions, see functions, first 
class 
first-class values, 121 
fish in a barrel, shooting, $448 
flips (copying collection), 271 
Float protocol, 652 
folding, 173 
higher-order functions, 128 
to implement set functions, 131 
methods, 645 
visualizations, 129 
F.,, 365 
form(s) 
judgment, 30 
syntactic, 15-17 
formation 
of generic-module types, 541 
of intersection types (Molecule), 
541 
of module types, 538-539 
formation rules, 345 (defined), 347, 384, 
see also type-formation rules 
template, 346 
formation, introduction, and elimina- 
tion, 347 
Molecule, 538 
forwarding (action), 277-278 
forwarding pointers, 272-273, 289 
Fraction protocol, 652 
fraction(s) in Smalltalk 
examples, 652 
implementation, 664-666 
frames (on evaluation stacks), 210-211 
free lists, 266, 289 
free occurrences 
of type variables, 371 
free type variables, 371 (defined) 
implementations, 371, 372 
inference rules, 371 
free variables, 173, 315-317, 318 
formal definition, 316-317 
in wScheme expressions, $328 
fresh locations, 144, 145 
in function application (uScheme), 
147 
fresh type constructors, 484 
fresh type variables, 433-434 
fresh variables, 165, 195, 196, S217 
freshness and generativity, 484 
from-space, 271 (defined) 
ftv (compute free type variables), 414 
in nano-ML, 433 
function(s) 
anonymous, 120 


function(s) (continued) 
first-class, 120-122, 172 
first-class, nested functions vs, 
121 
implementation, 122-124 
first-order, 90, 122, 172 
higher-order, see higher-order 
functions 
nested, see nested functions 
primitive 
environment ¢ and, 30 
typing rules, 348 
user-defined 
in Impcore environment ¢, 30 
variadic, 169, 322 (exercise) 
function?, 92 
function application 
Impcore, 36 
implementations 
Impcore, 50 
Scheme (C), 156-157 
puScheme (ML), 310 
puScheme-+, 231-234 
Lisp, 148 
pScheme, 147 
operational semantics 
Impcore, 36, 37 
Lisp, 148 
Scheme, 147, 150 
small-step semantics, 218-220 
type inference, 419, 421 
typing rules 
explicit substitutions, 419 
nano-ML, 414 (nondeterministic), 
421 (constraint-based) 
Typed Impcore, 336 
Typed puScheme, 365 
function composition, 125 
function environment ¢ (Impcore), 30 
function values, 120-122 
functional abstraction, 36 
functional programming 
object-oriented programming vs, 
624-625 
procedural programming vs, 205- 
206 
functors 
generic modules, 581 
ML, 581 
Prolog, $43, S52 


GADTs, 503, $25, $32-37 

garbage collection, 259 (defined), 289 
benefits, 257 
bugs, common, 280 
compacting, 288 
concurrent, 286 
conservative, 283, 288 
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garbage collection (continued) 
copying, 271-279, see also copying 
garbage collection 
debugging, 280-283, 291 
further reading, 291-292 
generational, 286, 289 
manual memory management vs, 
291 
mark-and-sweep, 266-271 
mark-compact, 283 
overhead, 259 
parallel, 286 
performance, 260, 270 
in real systems, 285-287 
write barrier, 286 
general, at least as, 410, 441 
generality 
of types, 410 
generalization, 413, 423-424, 442 
implementations, 434 
let binding, 425-428 
rationale, 435 
soundness, 427 
of types, 415 (defined), 423 
generalized algebraic data types, see 
GADTs 
generational garbage collection, 286 
generativity, 383, 483-485 (defined), 501 
in C, 484 
datatype definitions, 472 
in UML, 484 
in Molecule, 559, 578 
in real languages, 580 
of sealing in Molecule, 539 
specification (j:ML), 487 
in Standard ML, 484 
of syntactic forms, 484 
generic(s), see polymorphism 
generic (defined by recursion over 
types), 132 
generic (parametrically polymorphic), 
132, see also polymorphism 
generic module(s), 526, 540-541, 586 
curried, 575 
elimination of, 541 
examples, 552, 560 
instantiation of, 541 
introduction of, 541 
in real languages, 580 
generic-module types 
elaboration, 573 
examples, 540 
generic programming, 132 
global variables 
environments (Impcore), 28 
environments (jsSmalltalk), 678 
semantics, 151-152 


goals (Prolog), S49, S96 
going wrong, 22, 328 
goto, 201 
considered harmful, 201, 245 
grammars, 15, 69 
gray objects, 261 
in copying collection, 273 
examples, 275 
in mark-sweep collection, 269 
ground clauses (Prolog), S53 
ground terms (Prolog), S53, S96 
ground types, 408 


has? (uScheme function) 
algebraic laws, 103 
Haskell, 441 
head(s) 
of Prolog clauses, S52 
of Prolog rules, S97 
headroom 
in garbage collection, 259, 270 
heap(s), 289 
heap allocation, 289 
in uScheme-+, 263 
heap growth 
in copying collector, 278 
heap invariants 
array heaps, 552 
leftist heaps, 556 
heap(s), leftist, 555-557 
heap objects, 289 
heap pointer, 271 (defined) 
heaplimit, 271 
Heidi (broadcast on NBC), 526 
higher-order functions, 90, 121-122, 173 
algebraic laws (lists), 130 
for control flow, 136-138 
currying and uncurrying, 126 
for embedding, 312-314 
exercises, 187-189 
implementations, 129-131 
on lists, 127-131 
filtering, 127 
searching, 127-128 
transformation (mapping), 127 
for random-number generation, 
124-125 
Hindley-Milner type system, 401 
in real languages, 441 
Hoare triples (as metaphor for moves in 
blocks world), S83 
holes 
in Molecule typing contexts, 562 
in small-step semantics, 210-222, 
245 
in stack frames, 210-223, 226 
Horn clauses, $46, S91 
hp (heap pointer), 271 


hygiene, 166, 171 
in full Scheme macros, 171 
further reading, 175 
in substitution, 165-167 
in translations for wScheme, 162 


idempotence (of substitutions), 411 

identifier cross-reference in this book, 
39 

identity 


equivalence vs (in collections), 646 


identity substitution, 411 
idsubst (identity substitution), 411 
if expressions, see conditional expres- 
sions 
IFX vs IF, 42 
ill-behaved programs, 14 
ill-formed programs, 13 
ill-typed programs, 13 
images, Smalltalk, 701 
immutability 
of abstractions, 545 
Impcore, 12-87 
abstract syntax, 27-28 
concrete syntax, 12, 17-19 
environments, 28, 54-55 
evaluation, 20-23 
initial basis, 27 
interpreter 
environments, 44-45 
eval, 48-54 
interfaces, 41-47 
values, 43 
local variables, 66, 86 
operational semantics, 32-38 
semantics, informal, 20-22 
Simplified, 62 
imperative features, 402, 403 
implementation(s) 
allocation, 162 (Scheme) 
implementation modules, 527, 581 
implicit-data, 472-473 
impredicative polymorphism, 540, 577 
in modules, 578 
impure languages, 403 
induction principles, 116 
inductively defined data, 116 
specified by recursion equations, 
117 
inference rules, 31-32, see also oper- 
ational semantics, typing 
rules 
binary trees, defining, 109 
case expressions 
evaluation, 490-494 
type inference, 495-499 
data definitions (ML), 487-489 


inference rules (continued) 
elaboration 
PML, 489 
Molecule, 572 
evaluation 
case expressions, 490-494 
Impcore, 32-38 
pScheme, 145-152 
puScheme-+, 216-223 
pattern matching, 490-494 
form of, 31 
free type variables, 371 
free variables, 316-317 
instantiation, 56 
lists, defining, 116 
overloading (Molecule), 576 
pattern matching 
evaluation, 490-494 
type inference, 495-496 
as Prolog code, S45 
S-expressions, defining, 117 
soundness, 419 


substitution, capture-avoiding, 374 


type compatibility, 487-489 

type equivalence, 369-370 

type translation (jsML), 489 

types, see typing rules 
information hiding, 455, 586 

further reading, 587 
inhabitants 

of intersection types, 541 

of a subtype or supertype, 561 

of types, 334, 388 

of the unit type, 349 
inheritance, 610, 709 

collections and, 649 

effect on dispatch, 631-633 

examples, 620-622 

of instance variables, 614 
initial basis, 26 (defined), 69 

Impcore, 30 

pScheme, 97 

pSmalltalk, 636-653 

Molecule, 544 

nano-ML, 440 

Typed puScheme, 382 
initialization 

local variables (uScheme), 117 


Smalltalk examples, 615-616, 621 


of Smalltalk objects, 616, 624 
insertion sort, 101 

algebraic laws, 101 
instance(s), 442, 709 

of classes, 610 

of generic modules, 541 

of inference rules, 56 

of polymorphic functions, 356 

as qualified names, 541 


Concept index 


759 


Concept index 


760 


instance(s) (continued) 
of templates, 166 
instance methods, 614 
instance protocols, 613 
instance relation between types (<), 410 
instance variables, 614, 624, 709 
inheritance of, 614 
in the Smalltalk interpreter, 686 
visibility of, 624 
instantiation, 384, 409-413, 442 
automatic, 409 
examples (generic modules), 560 
examples (types), 358-359 
explicit, 409 
of generic modules, 541, 560 
typing rule, 575 
implementations, 376, 411, 434 
implicit, 409 
of inference rules, 56 
mistakes, common, with, 358 
of ML types, 304 
of ML type schemes, 410 
of polymorphic functions, 356 
of polymorphic values, 304 (ML), 
371-376 
quantified types and, 358 
typing rule, 365 
rationale, 435 
of templates for syntactic sugar, 
166 
typing rules 
generic modules, 575 
quantified types, 365 
integer(s), see also natural numbers 
implementations (Smalltalk), 
664, 666-667 
large, 666 
small, 666 
integer hierarchy, 651 
Integer protocol, 651 
interfaces 
in C code, 40 
design, 545-554 
design examples, 546-548 
memory management and, 257 
Molecule, 528-532 
in real languages, 580-583 
separate compilation and, 580 
Smalltalk, see protocols 
InternalError exception, S219 
interpreters 
Impcore, 38-55 
pScheme (C), 152-162 
Scheme (ML), 303-314 
pScheme-+, 223-239 
Smalltalk, 685-700 
Molecule, 579, S475-524 
nano-ML, 433-440 


interpreters (continued) 
Typed Impcore, 337-343 
intersection types 
“and” operator (A) and, 564 
components, 541 
elaboration, 573 
formation, 541 
idioms, 541 
inhabitants, 541 
Molecule, 541 
principal module types and, 567 
subtyping of, 564 
introduction and elimination forms 
creators, producers, and observers 
related to, 347 
introduction forms, 347, 384 
for functions, 348 
for generic modules, 541 
for modules, 539 
for pairs, 348 
for products, 348 
for quantified types, 359 
for sums, 349 
introduction rules, 345 (defined) 
template, 346 
invariants, 586, 673-677, see also repre- 
sentation invariants 
of stack-based eval, 227 
isKindOf: 
correct usage, 637 
isMemberOf: 
correct usage, 637 
it (automatically bound variable) 
in Impcore, 54 
in Scheme, 160 
iterators 
observers, as a species of, 645 
in Smalltalk, 645 


Java 
abstract types, 707 
Smalltalk vs, 707 

judgment(s), 30-31, 69 

judgment forms, xviii (table), 69 
expressing “may differ”, 33 
expressing “must differ”, 33 
expressing “must equal”, 33 


keyed collections 
implementations, 659-660 
pSmalltalk protocols, 646, 659 
KeyedCollection protocol, 647 
keys (in association lists), 105 
kind(s), 351-355, 384 
checking, 378-380 
implementation, 355-356 
UML, 466 
in nano-ML, unneeded, 409 


kind(s) (continued) 
of primitive type constructors 
Typed Scheme, 356 
slogan, 357 
of type constructors, 352 
kinding judgments, 354, 355 


lambda, 120-125 
dynamic scoping, 148 
exercises, 187-189 
implementations (C), 156 
implementations (ML), 310 
operational semantics, 147 
small-step semantics, 217 
typing rules 
nano-ML, 414 (nondeterministic), 
446 (constraint-based) 
Typed Scheme, 365 
lambda abstraction, 120-122, 173 
lambda-bound variables, 414, 442 
polymorphism and, 415 
lambda calculus, 241 
inspiration for Lisp, 89 
lambda expression, see lambda, lambda 
abstraction 
Lambda: The Ultimate (further read- 
ing), 174 
LAMBDAX vs LAMBDA, 42 
large integers, 666, see also multipreci- 
sion arithmetic, natural 
numbers 
invariants, 557 
LargeInteger 
class definition, 669 
private methods, 668 
protocol, 651 
laws, algebraic, see algebraic laws 
lazy evaluation, 241 
lazy sweeping, 266 
leftist heaps, 555-557 
length of a list 
algebraic laws, 98 
proof of laws, 114 
let 
implementations 
pScheme (C), 157-158 
pScheme (ML), 310 
pScheme-+, 231-232, 234-236 
Milner’s, 414, 425-428 
operational semantics, 146 
small-step semantics, 220 
syntactic sugar, 163 
typing rules 
nano-ML, 415 (nondeterministic), 
426 (constraint-based) 
Typed Scheme, 363 
let binding, 117-120 
let-bound variables, 414, 442 


letrec, 120, 135 
implementations 
uScheme (C), 158-159 
Scheme (ML), 311 
pUScheme-+, 234-236 
operational semantics, 146-147, 
364 
polymorphism and, 416 
small-step semantics, 221 
syntactic sugar, 163 
type annotations, 364 
type inference, 415, 420 
typing rules 
nano-ML, 415 (nondeterministic), 
420 (substitutions) 
Typed juScheme, 364 
let* 
assignment vs, 119 
implementations 
Scheme (C), 158 
Scheme (ML), 310 
puScheme-+ (lowering), 214, 
$350 
in Scheme, 118 
operational semantics, 146 
syntactic sugar, 163 
typing rules 
Typed juScheme, 364 
LETX vs LET, 42 
lexical analysis, $191 
lexical scoping, 148 
lexical structure, 14, 15 
of all bridge languages, 17 
LtML value constructors, 469-471 
lies, damn lies, and the logical interpre- 
tation of Prolog, S63 
linear search 
higher-order functions, 127-128 
Lisp 
bugs, 148 
conditional expressions, see cond 
function application, 148 
inspired by lambda calculus, 89 
recursion in, 90, 98 
list(s) 
algebraic laws, 130 
append laws, 99 
in C interpreters, 45-46 
circular, 673 
constructors, 318 
filtering 
function filter, 127 
methods select: andreject:, 
645 
visualizations, 129 
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list(s) (continued) 
folding 
functions foldl and foldr, 128 
method inject:into:, 645 
visualizations, 129 
higher-order functions, 127-131 
inference rules, defined by, 116 
insertion laws, 101 
mapping 
function map, 127 
method collect:, 645 
visualizations, 129 
UML, 473 
pScheme, 94 
Smalltalk examples, 648 
Smalltalk methods, 643-645, 649 
operations, 98-101 
notation, condensed, 99 
pattern matching on, 475-476 
primitives’ laws, 111 
principles for programming with, 
98-107 
representation for sets, 104-105 
reversal, 100 
searching 
functions exists? and all1?, 
127-128 
method detect:, 643 
selection 
function filter, 127 
methods select: andreject:, 
645 
visualizations, 129 
transformation 
function map, 127 
method collect:, 645 
list 
full Scheme function, 96 
pScheme primitive, 198 (exercise) 
List (uSmalltalk class), 674-677 
list comprehensions 
in a semantics for Prolog, $110 
how to implement, $114 
List protocol, 649 
literal expressions 
in Scheme, 95 
Smalltalk 
bootstrapping, 697-699 
evaluation, 691 
operational semantics 
Smalltalk, 680 
small-step semantics, 216 
Smalltalk-80, 701 
typing rules 
Typed Impcore, 335 
Typed juScheme, 363 
literate programming, 39 
live data, 289 


local variables 
initialization (Scheme), 117 
pScheme, 117-120 

location(s), 173 
fresh, 144, 145 
of uScheme-+ objects, 258 
Molecule, 535 
mutable, 122-124, 144, 145, 535 


location semantics, 144-152, 173, 677- 
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logic (as a programming language), S43- 


47 
logic programming, S96 
logical variables, S45, S96 
long-goto, 204, 208 
exercises, 251 
implementations, 237 
small-step semantics, 221-222 
long-label, 204, 208 
implementations, 236-237 
small-step semantics, 221-222 
loop(s) 
operational semantics 
Impcore, 35 
pScheme, 149 
typing rules 
Typed Impcore, 336 
Typed juScheme, 363 
loop invariants, 586 
lowering 
implementation, 226 
rules (uScheme-++), 214, 216 
semantics, 213-215 


Lua, for object-oriented programming, 


712 


macros, 171, 373 
further reading, 175 
hygienic, 171 (defined) 
magnitude(s), 709 
implementations, 656 
Magnitude (~Smalltalk class), 656 
Magnitude protocol, 649-651 
major (garbage) collection, 286 
managed heaps, 259 (defined), 289 
allocation in wScheme-+, 263 
size and growth, 262-263 
manifest types, 530, 538 
in C, 39 
as components, 538 
in real languages, 580 
mapping, 173 
higher-order functions, 127 
methods, 645 
visualizations, 129 
mark bits, 266, 290 


mark phase 
in uScheme-+ garbage collector, 
268-270 
mark-and-sweep garbage collection, 
266-271, 290 
performance, 270-271 
mark-compact garbage collection, 283 
marker methods, 636 
match compilation, 500-501, 503 
matching, see pattern matching 
materialization, 179 
“may differ,’ in judgment forms, 33 
member? (44Scheme function), 187 
membership in S-expressions 
algebraic laws, 103 
memory management, 257-299 
evaluation stacks, 229-230 
explicit, 289 
reference counting, 283-285 
memory safety, 240, 257, 290 
in C programs, 385 
message(s), 709 
private, see private messages 
to super, 621 
message cascades (Smalltalk-80), 706 
message categories, 613 
in Smalltalk-80, 703 
message names, 612 
arity, 627 
message not understood, 631, 709 
message passing, 609, 709 
basics, 610-611 
message patterns 
in Smalltalk-80, 703 
message selectors, 612 (defined), 631, 709 
message sends 
evaluation, 689-690 
operational semantics, 681-682 
metaclass(es), 630 (defined), 694-695 
in the wSmalltalk interpreter, 686 
representation, 686 
Metaclass (sSmalltalk class), 696-697 
metalanguages, 308 (defined), 318 
metatheoretic proofs, 59-66, 69, 116 
about data, 116-117 
construction (how to), 61-65 
example, 63-65 
small-step semantics and, 244 
utility of, 65-66 
metatheory, 59-66, 69, see also metatheo- 
retic proofs 
exercises, 195 
metavariables, 70 
in operational semantics, 31 
program variables vs, 19 
for syntax, 19 


method(s), 609, 614, 709 
class, 614 
complex, 662-673 
private, see private methods 
representations, 677, 686 
method dispatch, 610, 613, 631-633, 710 
conditionals vs, 623, 654-656 
examples, 632 
implementation, 690 
in Smalltalk, 623 
UML, 457-499 
abstract syntax, 485-486 
concrete syntax, 467 
predefined functions, 475-476 
predefined types, 464, 473-475 
values, 468, 486 
pScheme, 90-172 
abstract syntax, 144-145 
concrete syntax, 93 
initial basis, 97 
predefined functions, 96-100, 104- 
107, 125-128, $319-320 
primitive functions, 92-96 
primitives, 150-151 
values, 91-92, 145 
pScheme-+, 202-239 
abstract syntax, 225-226 
introduction, 202-205 
pSmalltalk, 610-700 
abstract machine, 678-679 
behaviors, 678-679 
concrete syntax, 627-629 
rationale, 611 
initialization, 616 
interfaces, see protocols 
predefined classes, 636-653 
primitive classes, 696-697 
primitives, 699-700 
operational semantics, 682 
values, 629-630 
Milner’s let, 414, 425-428 
Milner, Robin, 320, 401 
minor (garbage) collection, 286 
mixed arithmetic 
in wSmalltalk, 651, 723-724 
in Smalltalk-80, 705 
ML programming 
advantages and disadvantages, 
301-303 
C programming vs, 314-315 
conventions, 301-303 
quick reference, 320 
Modula-2, 586, 588 
Modula family, 526 
modular type checking, 558 
further reading, 588 
in real languages, 580 
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module(s), 525, 527, 587 
as components, 539 
definitions, 539 
desiderata, 527, 581-583 
elimination forms, 540 
evaluation, 541-542 
examples, 528-529 
exporting, 539 
further reading, 588 
generic, see generic modules 
introduction forms, 539 
nested, 539 
in real languages, 581 
objects and classes vs, 588 
parameters, 540 
polymorphism, 540-541 
programming style, 526 
in real languages, 527, 580-583 
recursive, 588 
representations, 541-542 
uses, 540 
module arrow --m->, 540 
module-arrow types 
elaboration, 573 
module types, 528, 587 
elaboration, 571-574 
formation, 538-539 
generic modules, 541 
independence from modules, 529 
principal, see principal module 
types 
in real languages, 581 
realization, 568 
rooted, 563 
strengthening, 559, 570 
subtyping, 564-566 
uninhabited, 566 
Molecule, 526-580 
concrete syntax, 536, 537 
core layer, 534-538 
module layer, 538-542 
overloading, 543-544, 576-577 
predefined modules, 544 
primitive types, 544 
Smalltalk vs, 615 
subtyping, 564-566 
syntactic categories, 539 
type system, 558-579 
design goals of, 558 
overloading, 576 
overview, 562 
values, 535 
monomorphic functions, 131, 173 
monomorphic type systems, 331, 344, 
384 
limitations, 351 
monotypes, 384, 408, 442 
msubsn, 567 (defined) 


multiple arguments 
functions consuming, 104 
multiple inheritance, 710 
multiple representations 
with data abstraction, 555-557 
in object-oriented programming, 
662-673 
multiprecision arithmetic, 557 
invariants, 557 
LML, alphabetized as micro-ML 
pScheme, alphabetized as micro- 
Scheme 
Smalltalk, alphabetized as micro- 
Smalltalk 
“must differ” 
in judgment forms, 33 
“must equal” 
as constraint ~, 420 
in judgment forms, 33 
mutability, 173, 545 
of abstractions, 625 
allocation and, 545 
Molecule, 534, 535 
of queues, S146 
in Smalltalk, 625 
mutable locations, see locations, muta- 
ble 
mutable reference cells, 188, 318 
mutable state 
of a machine, 11 
in Smalltalk class representa- 
tions, 694 
shared, 174 
in a resettable counter, 124 
mutable variables 
avoided by let*, 119 
mutablilty 
of abstractions, 545 
mutation, 402 
in full Scheme, 169 
observational equivalence and, 636 
mutators (class of operations), 112, 259, 
290 
in protocols, 614 


name(s) 
pSmalltalk denotations, 631 
qualified, 528, 540 
of value constructors for abstract 
syntax, 42 
name equivalence, 383, see also genera- 
tivity, type equivalence 
name resolution 
dynamic, 630 
pSmalltalk, 630-631 
static, 630 


nano-ML, 401-440 
abstract syntax, 404-405 
concrete syntax, 404 
LScheme vs, 401 
operational semantics, 405-407 
primitive type constructors, 412 
type system, 407-417 
Natural 
class-definition template, 670 
private methods, 671, 672 
protocol, 652-653 
natural deduction, 32, 70 
natural numbers, $13-22 
abstraction functions, represen- 
tations, and invariants, 669- 
673, $14-15 
nested functions, 121-122, 173 
nested modules, 539 
in real languages, 581 
nested patterns, 460-461 
new (ySmalltalk message), 624 
examples, 621 
new method 
implementation, 695 
Newton-Raphson technique, 652 
nil (wSmalltalk object), 630 
implementation, 696 
other languages vs, 630 
nondeterminism 
in calculi, 241 
in rules for nano-ML, 413-416 
in semantics, 241 
in typing, 416-417 
nonterminal symbols, 16 
:not-found exception, 209-210 
Noweb, 39 
null?, 92, 94 
nullary type constructors, 343 
number(s), 710 
implementations (~wSmalltalk), 
663-664 
Smalltalk-80, 705 
number?, 92 
number hierarchy, 649 
Number protocol, 649-653 
numeric coercions 
Smalltalk, 667-669 


O Lochlainn, Sean, forensic sorcerer, 
S45 
object(s), 455, 525, 609, 710 
abstract types vs, 625-627 
basics, 610-611 
equality and, 634 
modules vs, 588 
in Prolog, S43 
object(s) (Prolog), S96 


Object (Smalltalk class), 696 
implementation, 696 
protocol, 637 
object identity, 634 
observational equivalence vs, 635 
object languages, 308, 319 
object-oriented interfaces, see protocols 
object-oriented languages 
origins and evolution, 609 
object-oriented programming, 455, 587 
abstract classes, 656-662 
binary operations, 662-673 
classes, without, 707 
decision-making code, 654-656 
functional and procedural pro- 
gramming vs, 624-625 
historical development, 712 
invariants and, 673-677 
in Lua, 712 
sums of products in, 466 
technique, 654-677 
Objective C, 712 
observational equivalence, 110, 634 
in Impcore exercise, 77 
pSmalltalk, 635 
mutation and, 636 
object identity vs, 635 
observers (class of operations), 111, see 
also creators, producers, and 
observers 
elimination forms and, 347 
in protocols, 614 
OCaml, 399 
equality, 634 
occurrence equivalence, 383, see also 
generativity, type equiva- 
lence 
occurs check, S96 
in Prolog, S60 
in type inference, 429 
operational semantics, 29-32, 68, 70, see 
also small-step semantics 
abstract-machine, 211 
assignment (set) 
Impcore, 34 
pScheme, 145 
Smalltalk, 680 
big-step, 31 
blocks, 681 
car, 151 
cdr, 151 
class definitions, 685 
closures, 147, 681 
conditional expressions (if) 
Impcore, 34 
Scheme, 149 
cons, 151 
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operational semantics (continued) 


control operators, 210, 221-222, 
683-684 
Core psScheme-+, 215-223 
define 
Impcore, 38 
pScheme, 152 
dynamic scoping, 148 
function application 
Impcore, 36, 37 
Lisp, 148 
pScheme, 147, 150 
global variables, 151-152 
Impcore, 32-38 
lambda, 147 
lambda (dynamic scoping), 148 
letrec, 146, 364 
literal expressions 
LSmalltalk, 680 
loops 
Impcore, 35 
pScheme, 149 
lowering, 213-215 
message send, 681-682 
pScheme, 144-152 
Smalltalk vs, 677-678 
puScheme-+, 210-223 
Smalltalk, 677-685 
pScheme vs, 677-678 
uSmalltalk primitives, 682 
mutation-free, 405-407 
nano-ML, 405-407 
natural-deduction, 32 
nondeterministic, 241 
reduction, 215 
return 
puScheme-+, 222 
pLSmalltalk, 683-684 
sequencing (begin) 
Impcore, 35 
uScheme, 149 
Smalltalk, 679 
small-step, see small-step seman- 
tics 
stack-based, 210-213 
super, 680 
uses, 240-242 
val 
Impcore, 38 
pScheme, 151 
Smalltalk, 685 
nano-ML, 407 
variables 
Impcore, 32 
pScheme, 145 
Smalltalk, 680 
nano-ML, 405 


operator classifications, 111-112, 546, 
see also creators, producers, 
and observers 

optimized tail calls, 170, 214 

exercises, 251-252 
further reading, 246 
implementations, 238-239 
in real languages, 239 

order of evaluation, 35, 403 

order type ({4ML), 474 

overheads 

copying garbage collection, 279 
mark-sweep garbage collection, 
270 
overloading, 132, 383, 543-544 
elaboration (Molecule), 576 
evaluation (Molecule), 577 
examples, 543-544 
Molecule, 543, 576-577 
parametric polymorphism vs, 383 
in real languages, 584-585 
resolution, 544 
via type classes, 585, 589 
overriding (of methods), 614, 632, 710 


P (primitive function in identifier cross- 
reference), 39 
pages (units of heap), 267-268 
pair type(s) 
algebraic laws, 349 
typing rules, 348-349 
pair type (4sML), 464 
pangrams, 103 
parameters, accumulating, 101 
parametric polymorphism, see polymor- 
phism, parametric 
partial application, 125-127 
paths, see access paths 
pattern(s), 319, 501 
exhaustive, 499 
UML, 466 
nested, 460-461 
overlapping, 500 
redundant, 319, 500 
pattern matching, 319, 458, 501 
benefits, 501 
compilation, 500-501, 503 
compile-time checks, 499-500 
efficiency, 500-501, 503 
equational reasoning, 476-479 
in Erlang, 499 
evaluation, 490-494 
examples, 307, 309-312, 459-466, 
475-476 
exhaustive, 499 
in ML, 307 
nested patterns, 460-461 
operational semantics, 490-494 


pattern matching (continued) 
semantics, informal, 468-469 
syntactic sugar, 480-483 
type inference, 495-499 
typing rules, 495-496 (nondeter- 
ministic), 497-499 (constraint- 
based) 
ubiquitous, 480-483 
wildcards, 461 
phantom types, S37 
Pharo (Smalltalk system), 712 
phase(s) 
in language processing, 13-14 
phase distinction, $392 
7, see access paths 
m-calculus, 241, 247 
pictures (j:Smalltalk example), 616-618 
PLT Redex, 246 
polymorphic equality, 633 
polymorphic functions, 131 
recursive, 359-360 
polymorphic type(s), 319 
of list functions, 358 
polymorphic type systems, 328, 351- 
382, 384 
advantages, 351 
origins, 385 
polymorphic, recursive functions 
in Typed jzScheme, 359 
polymorphism, 132, 173, 332, 344, 384 
ad hoc, 132, 544, see also overload- 
ing 
impredicative, 540, 577 
in modules, 578 
lambda-bound variables and, 415 
in Scheme, 131-136 
in ML, 304 
modules, 526 
in Molecule 
nano-ML vs, 577 
Typed Scheme vs, 577-578 
in nano-ML vs Molecule, 577 
parametric, 132, 384, 401 
of lists, 116 
predicative, 540, 577 
programming technique, 133-135 
in Scheme, 133-135 
species of, three, 132 
subtype, 132, 646 
in Typed jzScheme vs Molecule, 
577-578 
polytypes, 385, 408, 442 
limited to type environments, 413 
predefined functions, 26, 70, see also ini- 
tial basis 
Impcore, 27 
UML, 475-476 


predefined functions (continued) 
pScheme, 96-100, 104-107, 125- 
128, $319-320 
nano-ML, 440 
Typed Impcore, 331 
predefined modules 
Molecule, 544 
predefined types 
UML, 464, 473-475 
predicate(s) (in Prolog), S45, S96 
predicate logic, S96 
predicate transformers, 246 
predicative polymorphism, 540, 577 
premises 
in inference rules, 31 
of a Prolog clause, S52 
preservation (proof technique), 240 
primitive classes (Smalltalk), 696-697 
primitive functions, 26, 70, see also ini- 
tial basis 
environment ¢ and, 30 
Impcore, 23-24 
pScheme, 92-96, 150-151, 160- 
162, 306, 312-314 
nano-ML, 440 
Typed Scheme, 381-382 
primitive type constructors 
Molecule, 544 
nano-ML, 412 
Typed Scheme, 381 
primitives, zSmalltalk, 699-700 
evaluation, 692-693 
operational semantics, 682 
principal module types, 561, 566-571 
computing (how to), 568-571 
intersection and, 567 
subtyping and, 566 
principal type(s), 416-417, 442 
testing, 402, 417 
principal type schemes, 417 
printu, 23 
private messages 
in Smalltalk collection classes, 
658 
Natural (jSmalltalk class), recom- 
mended for, 670, 672 
in Smalltalk, 623 
private methods, 616, 623, 710 
examples, 668 
pSmalltalk integer classes, 668 
Natural, 671, 672 
representations, exposing with, 
664 
in Smalltalk, 710 
procedural programming, 11, 70, 201- 
202, 204 
functional programming vs, 206- 
207 
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procedural programming (continued) 
object-oriented programming vs, 
624-625 
producers (class of operations), 111, see 
also creators, producers, and 
observers 
introduction forms and, 347 
in protocols, 614 
product types, 465 
algebraic laws, 349 
typing rules, 348 
program variables, see also variables 
metavariables vs, 19 
program verification, 553 
programming conventions 
C code, 39-40 
ML code, 301-303 
progress and preservation (proof tech- 
nique), 240 
projections, 308, 319, see also embed- 
dings 
Prolog, S43, S95 
arity, S50 
“backward” execution in, S56 
difference lists, S76 
logical interpretation, S55 
occurs check, S96 
primitive predicates, S68 
procedural interpretation, S61 
logical interpretation vs, S63, 
$95 
real, S90 
semantics, S91 
syntax, S90 
semantics, S55 
syntax, S52 
unification, S60 
prompt (control operator), 247 
proof(s) 
of abstract types, 588 
calculational, see calculational 
proofs, equational reasoning 
derivations, about, 59-66 
derivations as, 56-59 
metatheoretic, 59-66 
about data, 116-117 
in operational semantics, 55-66 
by structural induction, 115 
proof principles 
induction, 116 
proof techniques 
small-step semantics, 240 
proper tail recursion, 170, 174, see also 
optimized tail calls 
further reading, 246 
propositional logic, $97 
propositions as types, 347, 727-729 


protocols 
of objects, 613 
prototypes 
in object-oriented programming 
languages, 707 
public components, 538 
public names, 527 
pure expressions, 110 
pure languages, 403 


qualified names, 528, 540 

from generic modules, 541 
quantification, existential 

in algebraic data types, $25 
quantified types, 351, 356-360, 385 

elimination form, 358 

introduction form, 359 

in nano-ML, 407-408 
quasiquotation, 169, 197 (exercise) 


Racket (Scheme dialect), 168 
raise an exception, 583 
random-number generation 
higher-order functions, 124-125 
rational numbers 
in Smalltalk, 664-666 
reachability, 258-261, 290 
examples, 258-259 
in uScheme-+, 263-264 
realization 
of module types, 567, 568 
receiver(s), 610, 612, 710 
receiver-first syntax 
rationale, 611 
records 
encoded as S-expressions, 107-109 
exercises, 181, 196 
pScheme, 107-109 
Molecule, emulation in, 533 
syntactic sugar, 167-168 
Molecule, 542 
types, 383 
recursion 
difference lists, avoiding with, S77 
example of evaluation, 99 
on lists, 98-107 
modules, 588 
open, 710 
recursion equations (to define data), 117 
recursive definitions, 120 
recursive evaluation 
stack-based evaluation vs, 211-213 
recursive functions 
letrec and, 120, 135 
polymorphic, 359-360 
recursive, polymorphic functions 
in Typed psScheme, 359 


recursive types, 465 
examples, 463-464 
redefinition 
of Smalltalk methods, 614 
Redex, 246 
reduction 
in a calculus, 241 
in parsing, S194 
reduction semantics, 241, 245 
further reading, 246 
redundant patterns, 319, 500 
reference cells, mutable, 188, 318 
reference counting (memory manage- 
ment), 259, 283-285, 290 
reflection, 711 
in “Smalltalk, 630 
in Prolog, S93 
in Smalltalk-80, 630, 706-707 
relations, S97 
as a programming tool, S43-47 
rely-guarantee reasoning, 587 
to satisfy invariants, 552 
remembered set, 286 
renaming 
implementations, 375 
of type variables, 368-369 
of variables, S58 
representation invariants, 545, 550, 587, 
711 
binary search trees, 550 
circular lists, 673 
complex numbers, 551 
data structures, typical and, 549- 
551 
dictionaries, 549 
environments, 54 
examples, 551-554, 556, 664 
floating-point numbers 
(uSmalltalk), 652 
fractions (uwSmalltalk), 664 
large integers, 557 
leftist heaps, 556 
metaclasses, 694 
natural numbers, 670, 672 
priority queues, 550, 552 
rational numbers, 664 
sets, 548 
two-dimensional points, 551 
reserved words, 19 
reset (control operator), 247 
return, 202 
big-step judgment forms, 677 
in do: loop (Smalltalk), 657 
evaluation 
puScheme-+, 237 
LSmalltalk, 689 
LScheme-+ control operator, 202 
Smalltalk control operator, 677 


return (continued) 
operational semantics 
puScheme-+, 222 
Smalltalk, 683-684 
real implementations, 239 
small-step semantics, 221-222 
return addresses, 239 
revelations (of type identities), 530 
reversal of lists, see lists, reversal 
R” RS Scheme standards, 168 
root(s), 260-261, 290 
of absolute access paths (Mole- 
cule), 559 
in uScheme-+, 265 
of module types in environments, 
563 
rooted module types, 563 
rules, S97 
inference, see inference rules 
lowering (uScheme-+), 214 
in Prolog, S45 
typing, see typing rules 
run-time errors, 47 
checked, 40 
unchecked, 40 


S-expressions, 91-92, 174 
equality, 104 
fully general, 94 
functions involving, 103-104 
inference rules, defined by, 117 
limitations, 457 
ordinary, 92 
records, encoded with, 107-109 
trees, encoded with, 109-110 
safety properties, 240, see also memory 
safety, type safety 
satisfaction (of type-equality con- 
straints), 428 
satisfiability, see Boolean satisfiability 
satisfying assignment, 138 
to logical variables in Prolog, S49 
Scheme, see also jsScheme 
continuations, 172 
data abstraction in, 588 
equality, 633 
pScheme vs, 168-172 
Smalltalk blocks and, 638 
standards, 168 
scoping (dynamic, lexical, and static), 
148 
scrutinees, 458, 459, 468, 502 
evaluated in case expressions, 490 
sealing, 532, 539 
examples, 558-560 
in real languages, 580 
in the subtype relation, 566 
type checking, 564 
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sealing (continued) 
type constructors and, 535 
search 
with default result, 137 
higher-order functions for, 127- 
128 
using continuations, 136-143 
selection from lists 
higher-order functions, 127 
Smalltalk methods, 645 
visualizations, 129 
selectors, see observers 
self, 615, 711 
Self (programming language), 609, 707 
semantics, big-step, see operational se- 
mantics 
semantics, denotational, see denota- 
tional semantics 
semantics, operational, see operational 
semantics 
semantics, small-step, see small-step 
semantics 
semispaces, 271 
sentinels 
in “Smalltalk lists, 673 
separately compiled interfaces 
in real languages, 580 
sequenceable collections 
implementations, 661-662 
protocols, 648-649, 659 
SequenceableCollection protocol, 648 
sequencing, see begin 
set(s) 
of association lists, 132-135 
represented as lists, 104-105, 131 
set, see assignment, see also mutable 
variables 
set functions 
algebraic laws, 105 
polymorphism, 131-133 
shape(s), 611-612, 619-622 
protocol, 620 
Shape, Smalltalk-80 class, 702 
shared mutable state, see mutable state, 
shared 
shift (control operator), 247 
shift-reduce parsing, S194 
short-circuit Boolean operators, 164- 
165, 174, 195, 320 
side effects, 16, 20, 343 
signatures, 528, 581 
simple equality constraints, 420 
solving, 429-430 
Simplified Impcore, 62 
Simula 67, 586, 588, 609 
inspiration for Smalltalk, 707, 712 
simultaneous substitution, 166, 365 
single inheritance, 711 


Skolem types, S31 
slots (in object-oriented languages), 707 
small integers, 666 
small-step semantics, 71, 210-213, 215- 
223, 245 
function application, 218-220 
further reading, 246 
if, 217-218 
lambda, 217 
let, 220 
letrec, 221 
literal expressions, 216 
long-goto, 221-222 
long-label, 221-222 
metatheoretic proofs and, 244 
proof techniques, 240 
return, 221-222 
set, 217 
tracing, 224-225 
uses, 240-242 
variables, 217 
SmallInteger 
private methods, 668 
protocol, 651 
Smalltalk-80, 700-707 
binary messages, 703 
class hierarchies, 642, 704-707 
class instance variables, 704 
class variables, 704 
in simulations, $140 
Collection hierarchy, 705-706 
concrete syntax, 702-704 
development, 711 
images, 701 
literals, 701 
message cascades, 706 
numbers, 705 
as operating system, 700-701 
precedence, 703 
as programming language, 701- 
704 
reflection, 706-707 
syntax, 624 
UndefinedObject class, 654 
smart constructors 
in binary tries, 513 
solvers 
Boolean formulas, 139-143 
conjunctive normal form 
code, 143 
laws, 141, 142 
type-equality constraints, 418, 
428-431 
sorting, 101 
soundness, S97, see also type soundness 
of algebraic laws, 65 
generalization, 427 
Molecule, 578 


soundness (continued) 
proofs, 419 
rules for explicit substitutions, 419 
of type systems, 350 
type-lambda, 377-378 
Spock, 588 
square brackets 
in bridge languages, 117 
recommended usage, 117 
square roots, 652 
Squeak (Smalltalk system), 712 
stack(s) 
evaluation, 202, 730 
in real languages, 239 
tracing, 224-225 
stack allocation, 290 
stack-based evaluation 
examples, 212-213 
recursive evaluation vs, 211-213 
stack frames 
abstract syntax, 225-226 
evaluation contexts and, 242 
pScheme-+, 214 
Smalltalk, 678 
representation, 223-224 
standard libraries, 26, see also initial ba- 
sis 
Standard ML, 526 
equality, 633 
standards, Scheme, 168 
statements (syntactic category), 16 
static scoping, 148 
static typing, 327 
sample guarantees, 328 
static variables (in C), 124 
stone knives, 588 
stop-the-world garbage collection, 260 
stores, 174 
linear, 144 
in location semantics, 144 
single-threaded, 144, 154 
streams, $226-233 
for reading from files, S237 
strengthening, 559, 570, 571 
strict evaluation, 241 
struct types, 383 
structural equivalence, 383 
in type systems, 483 
structural induction, 115 
structured control-flow constructs, 11 
structured operational semantics, see 
operational semantics 
structured programming, 201-202 
structures (Standard ML form), 527 
subclasses, 711 
examples, 620-622 
subtypes vs, 713 


subclassResponsibility, 622, 624 
examples, 621 
subgoals, S97 
of a Prolog clause, S52 
substitution, 371-373, 409-412, 442, $97, 
see also substitutions 
capture-avoiding, see capture- 
avoiding substitution 
of equals for equals, 113 
evaluation via, 166, 731 
quantified types and, 356 
simultaneous, 365 
syntactic sugar and, 165-167 
in translations for wScheme, 162 
for type variables, 372 
uses, 165-166 
substitutions, see also substitution 
for abstract types, 567 
algebraic laws, 409-410 
composition, 410-411 
creation, 411 
explicit, 417 
typing judgment, 418 
generality, 442, S60 
implementations, 410 
interpretations, 409, 410 
from manifest types, 567 
Molecule, 579 
most general, 442 
type inference, 418-420 
for variables, 411 
subtype polymorphism, 132, 646 
subtyping, 587 
behavioral, 627, 708 
direction of, 561 
module types, 561, 564-566 
Molecule, 564-566 
rules for, 564 
subclassing vs, 713 
success continuations, 136, 139 
sum types, 465 
C, poor support in, 41 
rules, 349-350 
sums of products, 465-466, 502 
in C, 465 
in object-oriented languages, 466 
programming techniques, 465-466 
in Smalltalk, 624 
super, 711 
examples, 621 
idiomatic usage, 632-633 
messages to, 632 
operational semantics, 680 
superclasses, 610, 614, 624, 711 
Shape example, 620 
supertypes, direction of, 561 
symbol(s) (4zScheme values), 92 
symbol(s) (jsSmalltalk objects), 630 
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symbol?, 92 
symbol tables, see environments 
synerror, 47 
syntactic abstractions, see macros 
syntactic categories, 16, 71 
Molecule, 539 
types, 330 
syntactic forms, 15, 71 
syntactic proofs, 55-66 
syntactic sugar, 26, 66, 71, 162, 174 
&& and | |, S209 
begin, 167 
Boolean operators, 164-165 
cond, 163-164 
define, 152 
described as, 120 
Impcore, extending with, 66-67 
implementation, 195-197 
let, 163 
let*, 163 
letrec, 163 
in uScheme-+, 204-205 
Molecule, 535, 537 
pattern matching, 480-483 
records, 167-168 
Molecule, 542 
short-circuit operators, 164-165 
while*, do-while, and for, 66 
syntax, see abstract syntax or concrete 
syntax 
syntax errors, 47 
System F, 385 


@ (substitution), 409 
tables, see finite maps 
tail call(s), 170, see also optimized tail 
calls 
in continuation-passing style, 170 
further reading, 246 
implementations, 238-239 
optimized, 170, 214 
proper, 214 
tail-call optimization, see optimized tail 
calls 
tail position, 253 
tail recursion, see tail calls 
takewhile, 206 
talent imitates; genius steals, $245 
term(s), 333, 385, S97 
expressions, as theory-speak for, 
333 
in Prolog, S44 
term variables, 408 
theory (vs metatheory), 59 
throw, 202, 207-210 
examples, 208-210 
in real languages, 240 
throwing an exception, 207 


Tiger! Tiger! Tiger!, 56, 113, $13, S397 
TikzCanvas (Smalltalk class), 618-619 
to-space, 271 (defined) 
tokens, lexical, 14, $191 
tracing 
message sends, 640, 641 
pScheme calls, 198 
small-step evaluation, 224-225 
Smalltalk, $583 
transformation of lists 
higher-order functions, 127 
methods, 645 
tree(s) 
encoded as S-expressions, 109-110 
pScheme, 109-110 
traversal(s), 110, 118, 266 
traversal exercises, 181, 515 
tree-node functions 
algebraic laws, 109 
tricolor marking, 261-262, 290 
in concurrent and generational 
collectors, 286 
in copying collectors, 273 
examples, 274-276 
in mark-sweep collectors, 269 
tries 
exercises, 512-514 
trivial constraint, 420 
Trotsky, Leon, 136 
True (4Smalltalk class), 655 
true definitions, 18 
try-catch, 204, 207-210 
examples, 208-210 
in real languages, 240 
tuple types 
algebraic laws, 349 
typing rules, 348 
type(s), 385, 442, see also type systems 
algebraic notation for, 357 
arrays, 343 
dependent, 727 
elaboration (Molecule), 571-574 
inhabitants, 334 
modules, see module types 
Molecule, 535 
nano-ML, 407-409 
notation for, 357 
principal, 416-417 
quantified, 351, 356-360 
representation 
Typed jzScheme, 357 
Typed Impcore, 331 
uninhabited, 334 
user-defined, 459-476, 486-490, 
502 
uses, 327-328 
type abbreviations, 320, 484, 502, 529 
in ML, 303 


type abstraction, 385, see also 
type-lambda 
implicit, 413 
in ML, 412 
typing rules, 365 
type annotations, 401 
type application, 358, 385, see also in- 
stantiation 
implicit, 413 
in ML, 412 
typing rules, 365 
type ascriptions 
in Standard ML, 441 
type checkers, 329, 385, see also type 
checking 
arrays, 348 
LML, 489, 497, 498 
Molecule, $496-518 
nano-ML, 437-439 
Typed Impcore, 338-342 
Typed uScheme, 366-367 
type checking, 327, see also type 
checkers 
modular, 558 
in real languages, 580 
Molecule 
definitions, 570-571 
type classes, 589 
overloading and, 585 
type components, 538 
type constructors, 385 
M (set of), 487 
nano-ML, 407, 409 
nullary, 343 
representations (WML), 485 
sealing and, 535 
Typed Impcore, 333 
type declarations, manifest, 530 
typedef, 484 
type environments 
nano-ML, 407-409 
Typed Impcore, 333 
type equality, see also type equivalence 
dire warning about, 332 
type-equality constraints, 418, 420-431, 
442 
grammar, 420 
solving, 428-431 
typing judgment, 420 
type equivalence, 367-370 
Hindley-Milner, 412 
LML, 483-485 
Molecule, 559 
nano-ML, 412 
in real languages, 383 
rules, 369-370 
structural, 483 
Typed Impcore, 332 


type equivalence (continued) 
Typed Scheme, 370 
type erasure, 380 
type-formation rules, 345, 347 
kinds vs, 352-355 
modules, 538-539 
template, 346 
Typed Impcore, 334 
type generativity, 483-485, see also gen- 
erativity 
type identity 
examples, 559 
type inference, 327, 401, 442 
constraints for, 420-428 
decidability, 401 
implementations, 437-439 
performance, 430 
polymorphic types, 423-424 
substitutions for, 418-420 
type-lambda, 412, see also type abstrac- 
tion 
implicit, 413 
side conditions, 377-378 
soundness, 377-378 
in Typed psScheme, 352, 359 
typing rules, 365 
variable capture and, 377-378 
type-level expressions, 352, 357 
type parameters, 132, 304, 327, 356 
type predicates 
pScheme, 92 
for records, 108 
type safety, 328-329 
type schemes, 407-409, 442 
canonical, 433 
degenerate, 414 
principal, 417 
type soundness, 350-351 
type synonyms, see type abbreviations 
type systems, 327, 385 
design (Molecule), 577-579 
design goals (Molecule), 558 
further reading, 385 
loopholes, 376-377 
UML, 483-486, 495-499 
modules 
further reading, 588 
Molecule, 558-579 
environment lookup, 574-576 
formalism, 561-564 
overloading, 576-577 
overview, 562 
soundness, 578 
nano-ML, 407-417 
in real languages, 383 
restrictive, 328 
soundness, 350-351 
soundness (Molecule), 578 
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type systems (continued) 
subversion, 376-377 
Typed Impcore, 333-337 
Typed Scheme, 352-378 
type variables, 320, 356 
captured by a naive instantiation, 
373 
fresh, 433-434 
nano-ML, 407 
term variables vs, 408 
understanding, 356 
typing 
of definitions, 341, 366 
nondeterministic, 416-417 
typing contexts 
Molecule, 562 
typing judgments 
Molecule, 565 
nano-ML, 418 (explicit substitutions), 
420 (constraints) 
Typed Impcore, 335, 336 
Typed Scheme, 363 
typing rules 
arrays, 346-348 
arrow types, 348 
case expressions, 349, 495- 
496 (nondeterministic), 497- 
499 (constraint-based) 
functions, 348 
UML 495-496 (nondeterministic), 
497-499 (constraint-based) 
Molecule definitions, 569 
nano-ML, 412 (nondeterminis- 
tic), 416 (nondeterminis- 
tic), 421 (constraint-based), 
428 (constraint-based) 
pairs, 348-349 
pattern matching, 495-496 (non- 
deterministic), 497- 
499 (constraint-based) 
products, 348 
sums, 349-350, see also sum types 
tuple types, 348 
tuples, 348 
Typed Impcore, 334-337 
Typed Scheme, 361-366 
typical, 348-350 
unions, 349-350 


LML, alphabetized as micro-ML 
unchecked run-time errors, 40 

in getline_, S165 

in printing functions, 46 

from unspecified values, 151 
uncurried functions, 125 
uncurrying, 126 
UndefinedObject (wSmalltalk class), 

630, 696 


undelimited continuations, 243, 245 
understood 
message in Smalltalk, 631 
unfold, S230 
Unicode characters (Smalltalk), 641 
Unicode code points, 23 
unification, 417, 442, S97 
in type inference, 417 
unifiers, 418 
uninhabited module types 
examples, 566 
uninhabited types, 334 
union types 
rules, 349-350 
unit tests, 24-26 
unit type, 334 
unreachability, see reachability 
unsafe functions 
for printing, 46 
unsafe language features 
uses, 328-329 
unspecified values, 146 
in Scheme, 151 
misuse by careless persons, S328 
in Typed psScheme, 380 
unwinding (call stacks), 583 
uScheme, alphabetized as micro- 
Scheme 
use (extended-definition form), 23, 25 
user-defined functions 
in Impcore environment ¢, 30 
user-defined types, 459-476, 486-490, 
502 
Smalltalk, alphabetized as micro- 
Smalltalk 


val, 22 
operational semantics 
Impcore, 38 
pScheme, 151 
LSmalltalk, 685 
semantic comparison, 402 
typing rules 
nano-ML, 416 (nondeterministic), 
423 (constraint-based) 
Typed Impcore, 337 
Typed jScheme, 366 
val-rec, 402 
rationale, 362 
typing rules 
nano-ML, 416 (nondeterministic) 
Typed juScheme, 366 
valid derivations, 57-58 
value(s) 
UML, 468, 486 
pScheme, 91-92, 120, 145 
pSmalltalk, 629-630 
in Smalltalk semantics, 677 


value(s) (continued) 
Molecule, 535 
nano-ML, 405 
representations 
pScheme (C), 152-153 
pScheme (ML), 306 
pLSmalltalk, 685-686 
Typed Impcore, 332 
unspecified, 146 
value components, 538 
value constructors, 320, 457, 466, 502 
in Erlang, 499 
misspelled, 470 
in Molecule, 533 


names usable for abstract syntax, 


42 
in patterns, 458 
polymorphic, 462-463 
Prolog equivalent of, $52 
representations (jsML), 490 
value variables vs, 468-471 
value restriction 
exercises, 452 
in ML, $81 
value semantics, 174, 405-407 
value variables, 466 
value constructors vs, 468-471 
“varargs”, see variadic functions 
variable(s), see also metavariables, pro- 
gram variables, term vari- 
ables, type variables, value 
variables 
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